Gentoo Forums

Everytime I use a kernel with staircase cpu scheduler, watching movies (mpeg4, divx or xvid) and compiling, the movie becomes absolutely unwatchable. When I use a kernel running ingosched, i can do both at the time. wtf is wrong? both kernels have exactly the same configuration except the cpu scheduler. Now, I noticed an interesting anomally, the movie is unplayable on in mplayer. totem is no problem.

That's the whole purpose of CPU schedulers, ain't it?

What is ?
Making movies unwatchable ?
(Not offending, just wanting to know what you mean)

Wietze wrote:What is ?
Making movies unwatchable ?
(Not offending, just wanting to know what you mean)

If i start any sort of a compilation, such as emerging while watching a movie it becomes totally unwatchable, out of sync and choppy. This is on the staircase scheduler. If i put ingosched under the same stress, the movie is actually watchable, though not perfect. This is in mplayer.

petrjanda wrote:

Wietze wrote:What is ?
Making movies unwatchable ?
(Not offending, just wanting to know what you mean)

If i start any sort of a compilation, such as emerging while watching a movie it becomes totally unwatchable, out of sync and choppy. This is on the staircase scheduler. If i put ingosched under the same stress, the movie is actually watchable, though not perfect. This is in mplayer.

I was replying to frostschutz

Wietze wrote:What is ?
Making movies unwatchable ?
(Not offending, just wanting to know what you mean)

Sorry, I was being sarcastic.

The original poster is trying to run two very CPU intensive tasks (compiler and mplayer) at the same time and noticed that results are different when using different cpu schedulers. And that's the whole point of having cpu schedulers - if they all behaved the same way, there would be no point in having them, would there?

petrjanda wrote:wtf is wrong?

*shrug* Who knows? Maybe it's a bug in the scheduler, there have been bugs in the past... no one but the author (or similarly experienced kernel programmer) may know. Maybe staircase is just not cut out for the task you want to use it with. staircase has a few settings that can be changed in /sys/cpusched/staircase/ , like setting compute to 1... you could try fiddling with them and see if it changes anything.

Personally, I'd say you already have a scheduler that works, so why not use it?
Or is there any particular reason you want to stick with staircase?

(Just in case, if you want to use it because it's said to improve performance by 130%, forget it. No cpu scheduler can do that.)

frostschutz wrote:

Wietze wrote:What is ?
Making movies unwatchable ?
(Not offending, just wanting to know what you mean)

Sorry, I was being sarcastic.

The original poster is trying to run two very CPU intensive tasks (compiler and mplayer) at the same time and noticed that results are different when using different cpu schedulers. And that's the whole point of having cpu schedulers - if they all behaved the same way, there would be no point in having them, would there?

petrjanda wrote:wtf is wrong?

*shrug* Who knows? Maybe it's a bug in the scheduler, there have been bugs in the past... no one but the author (or similarly experienced kernel programmer) may know. Maybe staircase is just not cut out for the task you want to use it with. staircase has a few settings that can be changed in /sys/cpusched/staircase/ , like setting compute to 1... you could try fiddling with them and see if it changes anything.

Personally, I'd say you already have a scheduler that works, so why not use it?
Or is there any particular reason you want to stick with staircase?

(Just in case, if you want to use it because it's said to improve performance by 130%, forget it. No cpu scheduler can do that.)

This made me laugh at the Original Poster so hard. I mean, DUH! That's why you have a choice of schedulars. That's like having to move a ton of dirt from point A to point B and having a choice of a 1/2 ton pickup or a yugo to do the job, which one would you choose? I mean come on! Use your common sense for $DIETY sakes.

petrjanda, how long have you been using Linux? How long have you been on this forum? If this were a n00b asking these questions I would give a good solid technical answer but you .... All I can do is laugh at you. Sorry.

Since the topic of schedulers came up, I might as well ask here.

There are 3 available in my kernel, and all 3 were compiled into the kernel*. Is there a way to tell which is in use, and is there a way to switch without recompiling the kernel?

* Don't ask me why all 3 are there, I didn't set it. Just happened to stumble upon it the other day.

You could try your luck with (this works for I/O schedulers that are part of the vanilla kernel), I guess it's similar for CPU schedulers (at least they can be changed on runtime) but I don't know the exact filename right now sorry

Not sure how to interpret that. Nothing in the I/O scheduler help section mentions anything more specifically.

The schedulers are:
Anticipatory I/O scheduler
Deadline I/O scheduler
CFQ I/O scheduler.

Not that important really, I was just curious.

Thanks.

Err, well, you'll have to look at the file's contents, I guess... apparently you can configure different I/O schedulers for each hard disk (haven't actually tried that). I'm using CFQ for everything so that's what the /sys/block/hdx/queue/scheduler files are saying.

cat /sys/block/hdb/queue/scheduler


and original poster, are you running the compiling task on nice level? if your not, that's why.. it should chop, as it should be getting 50% of your resources. (on one of them it might be getting 0 one nanosecond, a 100 the next, then 0 again, and that could also cause chopping).

I was rather interested in technical aspect of things: Why does Staircase give "more" cpu time to compiling instead of mplayer when its meant to be desktop oriented ala responsiveness etc(hence why is said wtf is wrong?), This isn't a question which scheduler is simply overall "better" since ingosched has always performed better for me. Thanks.

neuron wrote:cat /sys/block/hdb/queue/scheduler


and original poster, are you running the compiling task on nice level? if your not, that's why.. it should chop, as it should be getting 50% of your resources. (on one of them it might be getting 0 one nanosecond, a 100 the next, then 0 again, and that could also cause chopping).

well i was interested in WHY Staircaise chops the video to total unwatchability, and ingosched chops it and its still watchable.

well ingosched could be using more resouces on scheduling, resulting in both tasks "taking longer" to finish, but lower latency, that'd be one reason to use one over the other (note, only a wild wild theory, not backed up by facts).

petrjanda wrote: well i was interested in WHY Staircaise chops the video to total unwatchability, and ingosched chops it and its still watchable.

Ahhhh you didn't say that in your original post.

petrjanda wrote: Everytime I use a kernel with staircase cpu scheduler, watching movies (mpeg4, divx or xvid) and compiling, the movie becomes absolutely unwatchable. When I use a kernel running ingosched, i can do both at the time. wtf is wrong? both kernels have exactly the same configuration except the cpu scheduler.

See? You sound like you are bitching because the two scedulars have different behaviour. Which is EXACTLY what they are supposed to do. They are designed to have different behaviour ON PURPOSE so you can choose which one works best in your situation.

Sorry if I offended you by laughing at you but I feel I am vindicated.

curtis119 wrote:

petrjanda wrote: well i was interested in WHY Staircaise chops the video to total unwatchability, and ingosched chops it and its still watchable.

Ahhhh you didn't say that in your original post.

petrjanda wrote: Everytime I use a kernel with staircase cpu scheduler, watching movies (mpeg4, divx or xvid) and compiling, the movie becomes absolutely unwatchable. When I use a kernel running ingosched, i can do both at the time. wtf is wrong? both kernels have exactly the same configuration except the cpu scheduler.

See? You sound like you are bitching because the two scedulars have different behaviour. Which is EXACTLY what they are supposed to do. They are designed to have different behaviour ON PURPOSE so you can choose which one works best in your situation.

Sorry if I offended you by laughing at you but I feel I am vindicated.

Thats ok. I thought its a public knowledge around the gentoo forums that Staircase is desktop/multimedia oriented , more responsiveness etc, thus I assumed (without having much technical knowledge of how Stairase works) that it would give multimedia applications such as mplayer "more" cpu time than to a non-desktop process like compiling. Of course I know I can renice it to make the movie watchable, but why should I when I specifically opted for a desktop scheduler such as staircase?

a scheduler can't know what on your system is multimedia and what isn't, all it can try to do is schedule as well as possible, ie spread resources as per nice levels. If you run compile tasks on the same priority as your multimedia tasks, they should get as much resources as them, and if they constantly request more they will get more.

The way staircase works is very simply by giving a process cpu time based on it's nice level if I remember correctly, so if a process is on nice'd 20 it'll get 20 times less resouces than a process that isn't.

A multimedia/desktop scheduler will be more tuned for latency than others will, a server system for example might schedule "slower" and not give you a good desktop experience, but better overall performance (although a tiny improvement if any at all).

neuron wrote:a scheduler can't know what on your system is multimedia and what isn't, all it can try to do is schedule as well as possible, ie spread resources as per nice levels. If you run compile tasks on the same priority as your multimedia tasks, they should get as much resources as them, and if they constantly request more they will get more.

The way staircase works is very simply by giving a process cpu time based on it's nice level if I remember correctly, so if a process is on nice'd 20 it'll get 20 times less resouces than a process that isn't.

A multimedia/desktop scheduler will be more tuned for latency than others will, a server system for example might schedule "slower" and not give you a good desktop experience, but better overall performance (although a tiny improvement if any at all).

Shouldnt the correct way to do it be that cpu cycles hungry application like emerge/compiling should not be allowed to overstep(by asking for more) their allocated cpu time at the expense of usability of other applications like mplayer? There should be some kind of automatic nicing. Most people use, even gentoo users, the GUI for GUI applications, and not for compiling unless you do emerge sync; emerge -uD world every 2-3 hours(maybe im dreaming?) I yet have to wait for the time where clicking forward and back in firefox will not make an mp3 playing in the background skip. This occurs on both Staircaise and Ingo sched. Are these problems even related to a scheduler or is it just bad programming on the part of mplayer/beep-media-player respectively or something completely else?

In /etc/make.conf add this line:
Change the "10" to whatever you want it to be. Portage will automatically nice any apps that it calls, like gcc, to that level (@any devs reading this - is this correct? Or does it only nice the actual emerge process itself?).

well i noticed that portage never plays nice with any of the hardcore desktop kernels. they work too well, and portage gets way over-prioritized. -ck-sources seems nice, but compling and multitasking heavy stuff just donest work. gentoo-sources seems to have a nice balance of speed and scheduling...

As was said before, CPU scheduler can't know what you are running and what your preferences are. You should tell it what you want it to do with a particular program, and niceness is the way to do so. And since it is not practical to call 'nice' for everything you run, you would do best to use something like this. It works nicely for me (pun intended), but is not the only app of it's kind. Find the one that suits you.

ExZombie wrote:As was said before, CPU scheduler can't know what you are running and what your preferences are. You should tell it what you want it to do with a particular program, and niceness is the way to do so. And since it is not practical to call 'nice' for everything you run, you would do best to use something like this. It works nicely for me (pun intended), but is not the only app of it's kind. Find the one that suits you.

Great! This is something ive been looking for! Thx.

EDIT: Im not noticing much changes. Ive added emerge, rsync and others as badexes and mplayer, and others as goodexes and there isnt much difference. in fact id say its worse than it was before.

@pjp

The topic was about *CPU* schedulers and you started about *I/O* schedulers...

@petrjanda

I also dislike the staircase one. For me the one in vanilla works quite OK. staircase has all kinds of side effect if you don't nice things (and nice values have a different meaning with this scheduler too). Perhaps you have to put your video to sched-iso (or alike) under staircase (look for schedtool). Well, for me it was too much hassle w/o noticing much (or any) improvements.

BTW, there is a patch from Peter Williams (I guess) called plugsched which enabled selctioning of different CPU schedulers - I guess even at run-time or at least boot-time.

FWIW there is a (potential) solution in *early* development.
The CKRM (class-based kernel resource management) is designed to allow you to specify (from userspace) limits on things like CPU usage, memory, I/O, socket usage ...
Define classes of work, and within that sub-classes. What's important to you (at a particular time) will be honoured regardless of scheduler.
It is currently in active re-write to reduce the kernel impact in response to kernel developer concerns.
Testing to follow.

Is probably more aimed at commercial/server systems, but I can see application generally - stay tuned, looks promising ...