Re: is RSDL an "unfair" scheduler too?
Bill Huey (hui) wrote: On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote: Dunno. I guess a lot of people would like to then manage the classes, which would be painful as hell. Sure ! I wouldn't like people to point the finger on Linux saying "hey look, they can't write a good scheduler so you have to adjust the knobs yourself!". I keep in mind that Solaris' scheduler is very good, both fair and interactive. FreeBSD was good (I haven't tested for a long time). We should manage to get something good for most usages, and optimize later for specific uses. Like I've said in a previous email, SGI schedulers have an interactive term in addition to the normal "nice" values. If RSDL ends up being too rigid for desktop use, then this might be a good idea to explore in addition to priority manipulation. However, it hasn't been completely proven that RSDL can't handle desktop loads and that needs to be completely explored first. It certain seems like, from the .jpgs that were posted earlier in the thread regarding mysql performance, that RSDL seems to have improved performance for those set ups so it's not universally the case that it sucks for server loads. The cause of this performance difference has yet to be pinpointed. I would say that RSDL is probably a bit better than default for server use, although if the server starves for CPU interactive processing at the console becomes leisurely indeed. The only thing I would like to address is the order of magnitude blips in latency of nice processes, which may be solved by playing with time slices. Con hasn't really commented on that (or I haven't read down to it). Also, bandwidth scheduler like this are a new critical development for things like the -rt patch. It would benefit greatly if the RSDL basic mechanisms (RR and deadlines) were to somehow slip into that patch and be used for a more strict -rt based scheduling class. It would be the basis for first-class control over process resource usage and would be a first in Linux or any mainstream kernel. I don't think that RSDL and -rt should be merged, but that's for Ingo and Con to discuss. I would love to see RSDL in mainline as soon as it is practical, marked as EXPERIMENTAL. This would be a powerful addition to Linux as a whole and RSDL should not be dismissed without these considerations. If it can somehow be integrated into the kernel with interactivity concerns addressed, then it would be an all out win for the kernel in both these areas. I don't think there are a lot of places where it underperforms the default scheduler, and it avoids a lot of jackpot cases where an overloaded system really bogs down. I would like to see more varied testing before any changes are made, unless a simple change would improve consistency of latency. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Mon, 19 Mar 2007, Radoslaw Szkodzinski wrote: Consider two servers, ^ ^ ^ Well, aren't we discussing desktops? Server admins can fine-tune the rights and CPU quotas per group. how many multi-user desktops are there? most desktops that I have seen run just about everything as a single user. I know that on mine, I don't want the updatedb process that runs as 'nobody' out of cron to have the same percentage of cpu as all the processes running as my userid. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
Helge Hafting wrote: Avi Kivity wrote: A fairly contrived example, but I see your point. Of course any system can be broken. I think that user-level scheduling is good for real multi user systems, where 'user' means a person, not an artificial entity. It's also good for a multi application server, where typically each service runs (or can be made to run) as a separate user. For a not so contrived example, look at email delivery. Some mailservers do all work as root (or some fixed email user) Some servers will switch to the UID of the user receiving the message, limiting the damage in case of buffer overflow etc. A fair amount of work is then done as that user - running the message through virus/spam-checks and then perhaps procmail. Actually that makes some sense with user level scheduling - delivering email is charged to the recipient instead of to the system. But I agree it's a surprising side effect and if this is ever implemented it should be optional. -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
Avi Kivity wrote: A fairly contrived example, but I see your point. Of course any system can be broken. I think that user-level scheduling is good for real multi user systems, where 'user' means a person, not an artificial entity. It's also good for a multi application server, where typically each service runs (or can be made to run) as a separate user. For a not so contrived example, look at email delivery. Some mailservers do all work as root (or some fixed email user) Some servers will switch to the UID of the user receiving the message, limiting the damage in case of buffer overflow etc. A fair amount of work is then done as that user - running the message through virus/spam-checks and then perhaps procmail. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
[what happened to the 'To' header?] David Schwartz wrote: I didn't suggest adding any unfairness! I suggested being fair by user/job/process instead of being fair by thread (which is actually unfair as it favors multi threaded processes over single threaded processes). Wouldn't that be unfair because it favors multi-user approaches over single-user approaches with the same number of processes? Consider two otherwise equivalent web server designs. They both use a helper process owned by the user who owns the file the web server is sending. One does a lot of work in the helper process, the other does very little. A "fair by user" scheduler would give the approach that puts more work in the helper process more CPU than the one that puts little work in the helper process. A fairly contrived example, but I see your point. Of course any system can be broken. I think that user-level scheduling is good for real multi user systems, where 'user' means a person, not an artificial entity. It's also good for a multi application server, where typically each service runs (or can be made to run) as a separate user. Being fair by user builds lots of assumptions into the scheduler. When they're not true, the scheduler becomes sub-optimal. For example, consider a web server that runs two very important tools, 'foo' and 'bar'. Rather than running them as root, they run as users 'foo' and 'bar' for security. "Fair to user" would mean that just because most other people are using 'foo', I get less CPU when I try to use 'foo', because the OS doesn't know the "real user", just the fake user who owns the process -- a security decision that has no relationship to fairness. This would be handled perfectly by a "fair to process" approach. Perhaps we need a scheduling class instead, defaulting to each user being in its own class, and system processes in another (or maybe more than one) class. Root can configure the relative priorities of the various classes according to preferences. As for favoring multi-threaded processes over single-threaded processes, sometimes that's what you want. Consider two servers, one using thread per job the other using process per job. Does it make sense to give the "process per job" server as much CPU to do a single task as the "thread per job" server gets for all the clients it's dealing with? That's why I wanted the job abstraction, which currently isn't communicated to the kernel (or at least not well). Within a user's quota, jobs are scheduled fairly. It's really more important that the scheduler be tunable and predictable. That way, we can tell it what we want and get it. But the scheduler cannot read our minds. For multiuser systems, it also has to provide predictable response to unpredictable loads. RSDL accomplishes part of this by removing heuristics. User-level scheduling does more by limiting the impact of a single user to 1/N of the system's cpu capacity, and similarly limits the impact of a single job to 1/number_of_active_jobs_for_this_user. -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On 3/19/07, David Schwartz <[EMAIL PROTECTED]> wrote: > I didn't suggest adding any unfairness! I suggested being fair by > user/job/process instead of being fair by thread (which is actually > unfair as it favors multi threaded processes over single threaded > processes). Wouldn't that be unfair because it favors multi-user approaches over single-user approaches with the same number of processes? Not necessarily. Use GID rotations too. And if you can't assign these properly, it's your own/your distro's fault. Consider two otherwise equivalent web server designs. They both use a helper process owned by the user who owns the file the web server is sending. One does a lot of work in the helper process, the other does very little. A "fair by user" scheduler would give the approach that puts more work in the helper process more CPU than the one that puts little work in the helper process. Indeed, it's a drawback. Though a configurable one. Being fair by user builds lots of assumptions into the scheduler. When they're not true, the scheduler becomes sub-optimal. For example, consider a web server that runs two very important tools, 'foo' and 'bar'. Rather than running them as root, they run as users 'foo' and 'bar' for security. "Fair to user" would mean that just because most other people are using 'foo', I get less CPU when I try to use 'foo', because the OS doesn't know the "real user", just the fake user who owns the process -- a security decision that has no relationship to fairness. This would be handled perfectly by a "fair to process" approach. Then, use a group quota. But checking that will be slower, and that overhead might kill other gains. As for favoring multi-threaded processes over single-threaded processes, sometimes that's what you want. Not on desktop. Typical multi-threaded workloads: - apache - some P2P clients - some audio servers/applications (small number of threads) Single-threaded is much more popular. Consider two servers, ^ ^ ^ Well, aren't we discussing desktops? Server admins can fine-tune the rights and CPU quotas per group. one using thread per job the other using process per job. Does it make sense to give the "process per job" server as much CPU to do a single task as the "thread per job" server gets for all the clients it's dealing with? Not necessarily. You see, the processes themselves are schedulable, the threads aren't. It's really more important that the scheduler be tunable and predictable. This kind of scheduler, yes. Except it's much more tunable than a simple fair or unfair scheduler, and much more suited to real-time applications. That way, we can tell it what we want and get it. But the scheduler cannot read our minds. That's why the per-user or per-group part would have to be optional. It just doesn't make much sense on single-user desktops. Then, RSDL design or even RSDL+bonus could be used. The bonus part would have to be really simple, e.g. priority inheritance for pipes, startup priority boost for nice 0 tasks. (warning - fork bombs. :P ) No sleep estimator. Maybe these would suffice? The interactive bonus would be disabled by default, same as per-user/per-group scheduling. Some syscalls would have to be added, maybe using LSM framework? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On 3/19/07, David Schwartz [EMAIL PROTECTED] wrote: I didn't suggest adding any unfairness! I suggested being fair by user/job/process instead of being fair by thread (which is actually unfair as it favors multi threaded processes over single threaded processes). Wouldn't that be unfair because it favors multi-user approaches over single-user approaches with the same number of processes? Not necessarily. Use GID rotations too. And if you can't assign these properly, it's your own/your distro's fault. Consider two otherwise equivalent web server designs. They both use a helper process owned by the user who owns the file the web server is sending. One does a lot of work in the helper process, the other does very little. A fair by user scheduler would give the approach that puts more work in the helper process more CPU than the one that puts little work in the helper process. Indeed, it's a drawback. Though a configurable one. Being fair by user builds lots of assumptions into the scheduler. When they're not true, the scheduler becomes sub-optimal. For example, consider a web server that runs two very important tools, 'foo' and 'bar'. Rather than running them as root, they run as users 'foo' and 'bar' for security. Fair to user would mean that just because most other people are using 'foo', I get less CPU when I try to use 'foo', because the OS doesn't know the real user, just the fake user who owns the process -- a security decision that has no relationship to fairness. This would be handled perfectly by a fair to process approach. Then, use a group quota. But checking that will be slower, and that overhead might kill other gains. As for favoring multi-threaded processes over single-threaded processes, sometimes that's what you want. Not on desktop. Typical multi-threaded workloads: - apache - some P2P clients - some audio servers/applications (small number of threads) Single-threaded is much more popular. Consider two servers, ^ ^ ^ Well, aren't we discussing desktops? Server admins can fine-tune the rights and CPU quotas per group. one using thread per job the other using process per job. Does it make sense to give the process per job server as much CPU to do a single task as the thread per job server gets for all the clients it's dealing with? Not necessarily. You see, the processes themselves are schedulable, the threads aren't. It's really more important that the scheduler be tunable and predictable. This kind of scheduler, yes. Except it's much more tunable than a simple fair or unfair scheduler, and much more suited to real-time applications. That way, we can tell it what we want and get it. But the scheduler cannot read our minds. That's why the per-user or per-group part would have to be optional. It just doesn't make much sense on single-user desktops. Then, RSDL design or even RSDL+bonus could be used. The bonus part would have to be really simple, e.g. priority inheritance for pipes, startup priority boost for nice 0 tasks. (warning - fork bombs. :P ) No sleep estimator. Maybe these would suffice? The interactive bonus would be disabled by default, same as per-user/per-group scheduling. Some syscalls would have to be added, maybe using LSM framework? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
[what happened to the 'To' header?] David Schwartz wrote: I didn't suggest adding any unfairness! I suggested being fair by user/job/process instead of being fair by thread (which is actually unfair as it favors multi threaded processes over single threaded processes). Wouldn't that be unfair because it favors multi-user approaches over single-user approaches with the same number of processes? Consider two otherwise equivalent web server designs. They both use a helper process owned by the user who owns the file the web server is sending. One does a lot of work in the helper process, the other does very little. A fair by user scheduler would give the approach that puts more work in the helper process more CPU than the one that puts little work in the helper process. A fairly contrived example, but I see your point. Of course any system can be broken. I think that user-level scheduling is good for real multi user systems, where 'user' means a person, not an artificial entity. It's also good for a multi application server, where typically each service runs (or can be made to run) as a separate user. Being fair by user builds lots of assumptions into the scheduler. When they're not true, the scheduler becomes sub-optimal. For example, consider a web server that runs two very important tools, 'foo' and 'bar'. Rather than running them as root, they run as users 'foo' and 'bar' for security. Fair to user would mean that just because most other people are using 'foo', I get less CPU when I try to use 'foo', because the OS doesn't know the real user, just the fake user who owns the process -- a security decision that has no relationship to fairness. This would be handled perfectly by a fair to process approach. Perhaps we need a scheduling class instead, defaulting to each user being in its own class, and system processes in another (or maybe more than one) class. Root can configure the relative priorities of the various classes according to preferences. As for favoring multi-threaded processes over single-threaded processes, sometimes that's what you want. Consider two servers, one using thread per job the other using process per job. Does it make sense to give the process per job server as much CPU to do a single task as the thread per job server gets for all the clients it's dealing with? That's why I wanted the job abstraction, which currently isn't communicated to the kernel (or at least not well). Within a user's quota, jobs are scheduled fairly. It's really more important that the scheduler be tunable and predictable. That way, we can tell it what we want and get it. But the scheduler cannot read our minds. For multiuser systems, it also has to provide predictable response to unpredictable loads. RSDL accomplishes part of this by removing heuristics. User-level scheduling does more by limiting the impact of a single user to 1/N of the system's cpu capacity, and similarly limits the impact of a single job to 1/number_of_active_jobs_for_this_user. -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
Avi Kivity wrote: A fairly contrived example, but I see your point. Of course any system can be broken. I think that user-level scheduling is good for real multi user systems, where 'user' means a person, not an artificial entity. It's also good for a multi application server, where typically each service runs (or can be made to run) as a separate user. For a not so contrived example, look at email delivery. Some mailservers do all work as root (or some fixed email user) Some servers will switch to the UID of the user receiving the message, limiting the damage in case of buffer overflow etc. A fair amount of work is then done as that user - running the message through virus/spam-checks and then perhaps procmail. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
Helge Hafting wrote: Avi Kivity wrote: A fairly contrived example, but I see your point. Of course any system can be broken. I think that user-level scheduling is good for real multi user systems, where 'user' means a person, not an artificial entity. It's also good for a multi application server, where typically each service runs (or can be made to run) as a separate user. For a not so contrived example, look at email delivery. Some mailservers do all work as root (or some fixed email user) Some servers will switch to the UID of the user receiving the message, limiting the damage in case of buffer overflow etc. A fair amount of work is then done as that user - running the message through virus/spam-checks and then perhaps procmail. Actually that makes some sense with user level scheduling - delivering email is charged to the recipient instead of to the system. But I agree it's a surprising side effect and if this is ever implemented it should be optional. -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Mon, 19 Mar 2007, Radoslaw Szkodzinski wrote: Consider two servers, ^ ^ ^ Well, aren't we discussing desktops? Server admins can fine-tune the rights and CPU quotas per group. how many multi-user desktops are there? most desktops that I have seen run just about everything as a single user. I know that on mine, I don't want the updatedb process that runs as 'nobody' out of cron to have the same percentage of cpu as all the processes running as my userid. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
Bill Huey (hui) wrote: On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote: Dunno. I guess a lot of people would like to then manage the classes, which would be painful as hell. Sure ! I wouldn't like people to point the finger on Linux saying hey look, they can't write a good scheduler so you have to adjust the knobs yourself!. I keep in mind that Solaris' scheduler is very good, both fair and interactive. FreeBSD was good (I haven't tested for a long time). We should manage to get something good for most usages, and optimize later for specific uses. Like I've said in a previous email, SGI schedulers have an interactive term in addition to the normal nice values. If RSDL ends up being too rigid for desktop use, then this might be a good idea to explore in addition to priority manipulation. However, it hasn't been completely proven that RSDL can't handle desktop loads and that needs to be completely explored first. It certain seems like, from the .jpgs that were posted earlier in the thread regarding mysql performance, that RSDL seems to have improved performance for those set ups so it's not universally the case that it sucks for server loads. The cause of this performance difference has yet to be pinpointed. I would say that RSDL is probably a bit better than default for server use, although if the server starves for CPU interactive processing at the console becomes leisurely indeed. The only thing I would like to address is the order of magnitude blips in latency of nice processes, which may be solved by playing with time slices. Con hasn't really commented on that (or I haven't read down to it). Also, bandwidth scheduler like this are a new critical development for things like the -rt patch. It would benefit greatly if the RSDL basic mechanisms (RR and deadlines) were to somehow slip into that patch and be used for a more strict -rt based scheduling class. It would be the basis for first-class control over process resource usage and would be a first in Linux or any mainstream kernel. I don't think that RSDL and -rt should be merged, but that's for Ingo and Con to discuss. I would love to see RSDL in mainline as soon as it is practical, marked as EXPERIMENTAL. This would be a powerful addition to Linux as a whole and RSDL should not be dismissed without these considerations. If it can somehow be integrated into the kernel with interactivity concerns addressed, then it would be an all out win for the kernel in both these areas. I don't think there are a lot of places where it underperforms the default scheduler, and it avoids a lot of jackpot cases where an overloaded system really bogs down. I would like to see more varied testing before any changes are made, unless a simple change would improve consistency of latency. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: is RSDL an "unfair" scheduler too?
> I didn't suggest adding any unfairness! I suggested being fair by > user/job/process instead of being fair by thread (which is actually > unfair as it favors multi threaded processes over single threaded > processes). Wouldn't that be unfair because it favors multi-user approaches over single-user approaches with the same number of processes? Consider two otherwise equivalent web server designs. They both use a helper process owned by the user who owns the file the web server is sending. One does a lot of work in the helper process, the other does very little. A "fair by user" scheduler would give the approach that puts more work in the helper process more CPU than the one that puts little work in the helper process. Being fair by user builds lots of assumptions into the scheduler. When they're not true, the scheduler becomes sub-optimal. For example, consider a web server that runs two very important tools, 'foo' and 'bar'. Rather than running them as root, they run as users 'foo' and 'bar' for security. "Fair to user" would mean that just because most other people are using 'foo', I get less CPU when I try to use 'foo', because the OS doesn't know the "real user", just the fake user who owns the process -- a security decision that has no relationship to fairness. This would be handled perfectly by a "fair to process" approach. As for favoring multi-threaded processes over single-threaded processes, sometimes that's what you want. Consider two servers, one using thread per job the other using process per job. Does it make sense to give the "process per job" server as much CPU to do a single task as the "thread per job" server gets for all the clients it's dealing with? It's really more important that the scheduler be tunable and predictable. That way, we can tell it what we want and get it. But the scheduler cannot read our minds. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an "unfair" scheduler too?
Op Sunday 18 March 2007, schreef Mike Galbraith: > On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote: > > Now for something constructive... by any chance is Mike running KDE > > instead of GNOME? > > Yes. > > -Mike Well, then, it might indeed be the KIOslave/pipe stuff. I experience sometimes horrible behaviour in certain apps who use a lot of KIO slaves (konqueror, kontact). Is there a solution to this? Cuz if there isn't, the majority of the Linux Desktops are going to regress with RSDL... -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. pgpOp5eO0rOgV.pgp Description: PGP signature
Re: [ck] Re: is RSDL an "unfair" scheduler too?
Willy Tarreau wrote: The per-user system would also be nice for servers, provided there are CPU/disc IO/swapper/... quotas or priorities at least. This is too hard to adjust. Imagine what would happen to your hundreds of apache processes when the "backup" user will start the rsync or tar+gzip, or when user "root" will start rotating and compressing the logs. Being able to group processes may be useful on servers, but it should be enabled on purpose by the admin. Sure, if implemented, it should default to the old behavior to avoid surprises. Maintenance jobs may have to be niced to avoid getting too much cpu. But it should also make hosting different applications on the the server much more predictable and easier (think of your hundreds of apache processes swamping an unrelated load when slashdotted). -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an "unfair" scheduler too?
On Sun, Mar 18, 2007 at 07:54:20AM +0100, Radoslaw Szkodzinski wrote: > On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: > >On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote: > > > >> Maybe we're all discussing the problem because we have reached the point > >> where we need two types of schedulers : one for the desktop and one for > >> the servers. After all, this is already what is proposed with preempt, > >> it would make sense provided they share the same core and avoid ifdefs > >> or unused structure members. Maybe adding OPTIONAL unfairness to RSDL > >> would help some scenarios, but in any case it is important to retain > >> the default fairness it provides. > > > >Bingo. > > > > Sounds like Staircase's interactive mode switch, except this actually > requires writing additional code. > > The per-user system would also be nice for servers, provided there are > CPU/disc IO/swapper/... quotas or priorities at least. This is too hard to adjust. Imagine what would happen to your hundreds of apache processes when the "backup" user will start the rsync or tar+gzip, or when user "root" will start rotating and compressing the logs. Being able to group processes may be useful on servers, but it should be enabled on purpose by the admin. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sun, Mar 18, 2007 at 07:37:02AM +0100, Mike Galbraith wrote: > On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote: > > > Like I've said in a previous email, SGI schedulers have an interactive > > term in addition to the normal "nice" values. If RSDL ends up being too > > rigid for desktop use, then this might be a good idea to explore in > > addition to priority manipulation. > > I've done that already (ain't perfect yet, maybe never be). The hard > part is making it automatic, and not ruining the good side of RSDL in > the process. I can't fully qualify what aspects of the X server that's creating this problem. More experimentation is needed (various display drivers, etc...) should be played with to see what kind of problematic situations arise. It's a bit too new with too few users to know what are the specific problems just yet. Your case is too sparse for it to be an completely exhaustive exploration of what's failing with this scheduler. There's a policy decision that needs to be made of whether adding another term to the scheduler calcuation is blessed or not. My opinion is that is should be. Meanwhile, we should experiment more with different configurations. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sun, Mar 18, 2007 at 07:37:02AM +0100, Mike Galbraith wrote: On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote: Like I've said in a previous email, SGI schedulers have an interactive term in addition to the normal nice values. If RSDL ends up being too rigid for desktop use, then this might be a good idea to explore in addition to priority manipulation. I've done that already (ain't perfect yet, maybe never be). The hard part is making it automatic, and not ruining the good side of RSDL in the process. I can't fully qualify what aspects of the X server that's creating this problem. More experimentation is needed (various display drivers, etc...) should be played with to see what kind of problematic situations arise. It's a bit too new with too few users to know what are the specific problems just yet. Your case is too sparse for it to be an completely exhaustive exploration of what's failing with this scheduler. There's a policy decision that needs to be made of whether adding another term to the scheduler calcuation is blessed or not. My opinion is that is should be. Meanwhile, we should experiment more with different configurations. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an unfair scheduler too?
On Sun, Mar 18, 2007 at 07:54:20AM +0100, Radoslaw Szkodzinski wrote: On 3/18/07, Mike Galbraith [EMAIL PROTECTED] wrote: On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote: Maybe we're all discussing the problem because we have reached the point where we need two types of schedulers : one for the desktop and one for the servers. After all, this is already what is proposed with preempt, it would make sense provided they share the same core and avoid ifdefs or unused structure members. Maybe adding OPTIONAL unfairness to RSDL would help some scenarios, but in any case it is important to retain the default fairness it provides. Bingo. Sounds like Staircase's interactive mode switch, except this actually requires writing additional code. The per-user system would also be nice for servers, provided there are CPU/disc IO/swapper/... quotas or priorities at least. This is too hard to adjust. Imagine what would happen to your hundreds of apache processes when the backup user will start the rsync or tar+gzip, or when user root will start rotating and compressing the logs. Being able to group processes may be useful on servers, but it should be enabled on purpose by the admin. Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an unfair scheduler too?
Willy Tarreau wrote: The per-user system would also be nice for servers, provided there are CPU/disc IO/swapper/... quotas or priorities at least. This is too hard to adjust. Imagine what would happen to your hundreds of apache processes when the backup user will start the rsync or tar+gzip, or when user root will start rotating and compressing the logs. Being able to group processes may be useful on servers, but it should be enabled on purpose by the admin. Sure, if implemented, it should default to the old behavior to avoid surprises. Maintenance jobs may have to be niced to avoid getting too much cpu. But it should also make hosting different applications on the the server much more predictable and easier (think of your hundreds of apache processes swamping an unrelated load when slashdotted). -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an unfair scheduler too?
Op Sunday 18 March 2007, schreef Mike Galbraith: On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote: Now for something constructive... by any chance is Mike running KDE instead of GNOME? Yes. -Mike Well, then, it might indeed be the KIOslave/pipe stuff. I experience sometimes horrible behaviour in certain apps who use a lot of KIO slaves (konqueror, kontact). Is there a solution to this? Cuz if there isn't, the majority of the Linux Desktops are going to regress with RSDL... -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. pgpOp5eO0rOgV.pgp Description: PGP signature
RE: is RSDL an unfair scheduler too?
I didn't suggest adding any unfairness! I suggested being fair by user/job/process instead of being fair by thread (which is actually unfair as it favors multi threaded processes over single threaded processes). Wouldn't that be unfair because it favors multi-user approaches over single-user approaches with the same number of processes? Consider two otherwise equivalent web server designs. They both use a helper process owned by the user who owns the file the web server is sending. One does a lot of work in the helper process, the other does very little. A fair by user scheduler would give the approach that puts more work in the helper process more CPU than the one that puts little work in the helper process. Being fair by user builds lots of assumptions into the scheduler. When they're not true, the scheduler becomes sub-optimal. For example, consider a web server that runs two very important tools, 'foo' and 'bar'. Rather than running them as root, they run as users 'foo' and 'bar' for security. Fair to user would mean that just because most other people are using 'foo', I get less CPU when I try to use 'foo', because the OS doesn't know the real user, just the fake user who owns the process -- a security decision that has no relationship to fairness. This would be handled perfectly by a fair to process approach. As for favoring multi-threaded processes over single-threaded processes, sometimes that's what you want. Consider two servers, one using thread per job the other using process per job. Does it make sense to give the process per job server as much CPU to do a single task as the thread per job server gets for all the clients it's dealing with? It's really more important that the scheduler be tunable and predictable. That way, we can tell it what we want and get it. But the scheduler cannot read our minds. DS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an "unfair" scheduler too?
On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote: > Maybe we're all discussing the problem because we have reached the point > where we need two types of schedulers : one for the desktop and one for > the servers. After all, this is already what is proposed with preempt, > it would make sense provided they share the same core and avoid ifdefs > or unused structure members. Maybe adding OPTIONAL unfairness to RSDL > would help some scenarios, but in any case it is important to retain > the default fairness it provides. Bingo. Sounds like Staircase's interactive mode switch, except this actually requires writing additional code. The per-user system would also be nice for servers, provided there are CPU/disc IO/swapper/... quotas or priorities at least. All in all, I'd hate to see mldonkey eating 1/3 of CPU time, just because it runs as another user. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote: > Like I've said in a previous email, SGI schedulers have an interactive > term in addition to the normal "nice" values. If RSDL ends up being too > rigid for desktop use, then this might be a good idea to explore in > addition to priority manipulation. I've done that already (ain't perfect yet, maybe never be). The hard part is making it automatic, and not ruining the good side of RSDL in the process. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote: > Maybe we're all discussing the problem because we have reached the point > where we need two types of schedulers : one for the desktop and one for > the servers. After all, this is already what is proposed with preempt, > it would make sense provided they share the same core and avoid ifdefs > or unused structure members. Maybe adding OPTIONAL unfairness to RSDL > would help some scenarios, but in any case it is important to retain > the default fairness it provides. Bingo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote: > > Dunno. I guess a lot of people would like to then manage the classes, > > which would be painful as hell. > > Sure ! I wouldn't like people to point the finger on Linux saying "hey > look, they can't write a good scheduler so you have to adjust the knobs > yourself!". I keep in mind that Solaris' scheduler is very good, both > fair and interactive. FreeBSD was good (I haven't tested for a long time). > We should manage to get something good for most usages, and optimize > later for specific uses. Like I've said in a previous email, SGI schedulers have an interactive term in addition to the normal "nice" values. If RSDL ends up being too rigid for desktop use, then this might be a good idea to explore in addition to priority manipulation. However, it hasn't been completely proven that RSDL can't handle desktop loads and that needs to be completely explored first. It certain seems like, from the .jpgs that were posted earlier in the thread regarding mysql performance, that RSDL seems to have improved performance for those set ups so it's not universally the case that it sucks for server loads. The cause of this performance difference has yet to be pinpointed. Also, bandwidth scheduler like this are a new critical development for things like the -rt patch. It would benefit greatly if the RSDL basic mechanisms (RR and deadlines) were to somehow slip into that patch and be used for a more strict -rt based scheduling class. It would be the basis for first-class control over process resource usage and would be a first in Linux or any mainstream kernel. This would be a powerful addition to Linux as a whole and RSDL should not be dismissed without these considerations. If it can somehow be integrated into the kernel with interactivity concerns addressed, then it would be an all out win for the kernel in both these areas. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
Willy Tarreau wrote: On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote: On Sat, 17 Mar 2007, William Lee Irwin III wrote: One issue this raises is prioritizing users on a system, threads within processes, jobs within users, etc. Doing some "classing" even by just euid might be a good idea. It would actually catch X automatically most of the time, because the euid of the X server is likely to be root, so even for the "trivial" desktop example, it would kind of automatically mean that X would get about 50% of CPU time even if you have a hundred user clients, just because that's "fair" by euid. Warning: all these ideas seem interesting for desktop, but are definitely not for servers. I found RSDL to be excellent on servers, compared to mainline in which some services are starving under load. I can understand that on the desktop people want some unfairness, and I like the pgrp idea for instance. But this one will certainly fail on servers, or make the admins get grey hair very soon. I didn't suggest adding any unfairness! I suggested being fair by user/job/process instead of being fair by thread (which is actually unfair as it favors multi threaded processes over single threaded processes). Maybe we're all discussing the problem because we have reached the point where we need two types of schedulers : one for the desktop and one for the servers. After all, this is already what is proposed with preempt, it would make sense provided they share the same core and avoid ifdefs or unused structure members. Maybe adding OPTIONAL unfairness to RSDL would help some scenarios, but in any case it is important to retain the default fairness it provides. I hope not. I think that reducing the timeslice base, combined with renicing X all the way to hell should suffice. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote: > Now for something constructive... by any chance is Mike running KDE > instead of GNOME? Yes. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote: > > > On Sat, 17 Mar 2007, William Lee Irwin III wrote: > > > > One issue this raises is prioritizing users on a system, threads within > > processes, jobs within users, etc. > > Doing some "classing" even by just euid might be a good idea. It would > actually catch X automatically most of the time, because the euid of the X > server is likely to be root, so even for the "trivial" desktop example, it > would kind of automatically mean that X would get about 50% of CPU time > even if you have a hundred user clients, just because that's "fair" by > euid. Warning: all these ideas seem interesting for desktop, but are definitely not for servers. I found RSDL to be excellent on servers, compared to mainline in which some services are starving under load. I can understand that on the desktop people want some unfairness, and I like the pgrp idea for instance. But this one will certainly fail on servers, or make the admins get grey hair very soon. Maybe we're all discussing the problem because we have reached the point where we need two types of schedulers : one for the desktop and one for the servers. After all, this is already what is proposed with preempt, it would make sense provided they share the same core and avoid ifdefs or unused structure members. Maybe adding OPTIONAL unfairness to RSDL would help some scenarios, but in any case it is important to retain the default fairness it provides. > Dunno. I guess a lot of people would like to then manage the classes, > which would be painful as hell. Sure ! I wouldn't like people to point the finger on Linux saying "hey look, they can't write a good scheduler so you have to adjust the knobs yourself!". I keep in mind that Solaris' scheduler is very good, both fair and interactive. FreeBSD was good (I haven't tested for a long time). We should manage to get something good for most usages, and optimize later for specific uses. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
William Lee Irwin III wrote:
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound single
threaded threaded process.
A job with many processes will overwhelm a job with a single process.
A user with many jobs can starve a user with a single job.
I don't think the problem here is heuristics, rather that the
scheduler's manages cpu quotas at the task level rather than at the user
visible level. If scheduling were managed at all three hierarchies I
mentioned ('job' is a bit artificial, but process and user are not) then:
- if N users are contending for the cpu on a multiuser machine, each
should get just 1/N of available cpu power. As it is, a user can run a
few of your #1 workloads (or a make -j 20) and slow every other user down
- your example would work perfectly (if we can communicate to the kernel
what a job is)
- multi-threaded processes would not get an unfair advantage
I like this notion very much. I should probably mention pgrp's' typical
association with the notion of "job," at least as far as shells go.
One day I might understand what pgrp, sessions, and all that stuff is.
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc. Maybe sessions would make sense, too,
and classes of users, and maybe whatever they call the affairs that pid
namespaces are a part of (someone will doubtless choke on the hierarchy
depth implied here but it doesn't bother me in the least). It's not a
deep or difficult issue. There just needs to be some user API to set the
relative scheduling priorities of all these affairs within the next higher
level of hierarchy, regardless of how many levels of hierarchy (aleph_0?).
I think it follows naturally.
Note that more than the scheduler needs to be taught about this. The
page cache and swapper should prevent a user from swapping out too many
of another user's pages when there is contention for memory; there
should be per-user quotas for network and disk bandwidth, etc. Until
then people who want true multiuser with untrusted users will be forced
to use ugly hacks like virtualization. Fortunately it seems the
container people are addressing at least a part of this.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote: > Con Kolivas wrote: > > Now for something constructive... by any chance is Mike running KDE > instead of GNOME? I only had a short time to play because I had to look > at another problem in 2.6.21-rc3 (nbd not working), so the test machine > is in use. But it looked as if behavior was not as smooth with KDE. May > that thought be useful. Now i must say here, i use KDE, and have been testing 0.31, and i have been observing all the effects, in contrast with vanilla and staircase. this is on 2.6.20 I do not notice kde being slower, in fact i notice various interactivity "speedups" compared to mainline. first one i noticed(because i deliberately tested) was kicker. Kickers hide function was very very smooth during boot, and still is under load. It is not entirely as smooth under vanilla during boot(i suspect IO issue), under staircase it is, however under huge loads, it even is not smooth under staircase. then i started my konsole, and the one thing i immediately noticed was that zsh started instantly, usually i can see/(feel) zsh starting, as in it takes like 0.2 before my prompt comes. This is simply gone now with rsdl, behavior used to be the same in vanilla/rsdl. But the most interresting, and dare i say, completely unexpected things are much more important. I have for a long time had issues with tvtime, if i did stuff like move windows, tvtime would drop frames, or simply hovering javascript stuff on sites in konqueror, (this seemed to be introduced in 2.6.~5+), cause in EARLY 2.6 i did not have this problem, but it was the same in staircase and vanilla. But this is gone completely, tvtime no longer drops any frames when doing this. Another thing i noticed, which almost blew my mind as badly as with tvtime, was with wine, and world of warcraft(and nvidia blob driver, but this IS what many "desktop" users runs). While loading a level, the sound no longer skipped. This problem afaik, EVERYBODY which runs wine +wow has(unless they change the buffer size to ridicoulesly high which annoys gameplay). And more playing wow has shown me that rsdl seems to be doing an extremely good job of not letting other tasks interfere. For example i have spamasassin going quite very often (every minute, for lots of accounts), and this usually kills all sorts of high performance opengl stuff, causing severe stuttering, but with RSDL i only noticed my framerate dropping, but no strange stuttering as i usually experience, only lowered fps, which to me is quite natural, as spamasassin now has to use cpu. the last of my immediate observations are ktorrent. my ktorrent has LOTS of open fd's (in fact like ~5-6k), and the application tends to be very sluggish, but that is not so anymore. And now for the side effects i have observed. The only down right "regression" (which i wouldnt even call it, cause its a NATURAL thing when other stuff uses cpu) is that when i play a movie in kaffeine, and move the kaffeine window insanely fast all over the desktop, the audio skipped once, the strange thing is, even if i keep moving it, it does not skip any more, only the one time when you start to move it. But 720p h264 does take SOME cpu to decode, so i dont feel that this is unfair. i have however with X observed that under high load(720p h264 video playback, while doing video encoding, ktorrent running, and make running) that windows take longer time to redraw in X, if i move windows over each other, but not really a problem. another effect i have observed is that stuff does not stutter as much when under load, it simply gets slower.(but i suppose thats what i said when describing the good effects i have noticed) it should be noted that i have not reniced a single thing, and this is a singlecore amd64 2ghz with 1.5gb ram. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
You initially said you were pleased with this design.
I said that 2 years ago about the staircase scheduler and i am still
saying this about RSDL today. That doesnt make my position automatically
correct though :-) For example i wrote and maintained the 4g:4g patchset
for over 2 years and still that was no guarantee of it making sense
upstream ;) And it was a hell of a lot of work (much uglier and nastier
work than any scheduler hacking and tuning, believe me), and it was
thrown away as a cute but unnecessary complication we dont need. So
what? To me what matters is the path you walk, not the destination you
reach.
in terms of RSDL design, i like it, still i'm kind of asking myself
'couldnt something in this direction be done in a much simpler and less
revolutionary way'? For example couldnt we introduce per-priority level
timeslice quotas in the current scheme as well, instead of the very
simplistic and crude STARVATION_LIMIT approach? Furthermore, couldnt we
make the timeslices become smaller as the runqueue length increases, to
make starvation less of a problem? It seems like the problem cases with
the current scheduler arent so much centered around the interactivity
estimator, it is more that timeslices get distributed too coarsely,
while RSDL distributes timeslices in a more finegrained way and is thus
less suspect to starvation under certain workloads.
Yes. The "doorknob scheduler" was a scheduler which worked as follows:
the runnable processes in the system were put in a priority sorted list
and counted. Then the length of one cycle (turn) was divided by the
number of processes and that was the timeslice. In the next version
upper and lower limits were put on the length of a timeslice, so the
system didn't get eaten by context switches under load or be jerky under
light load. That worked fairly well.
Then people got into creating unfairness to address what they thought
were corner cases, the code turned into a plumber's nightmare, and
occasional jackpot cases created occasional (non-reproducible) hangs.
Finally management noted that the peripherals cost three times as much
as the CPU, so jobs doing i/o should run first. That made batch run like
the clappers of hell, and actually didn't do all the bad things you
might expect. User input was waitio, disk was waitio, response was about
as good as it could be for that hardware.
===> it might be useful to give high priority to a process going from
waitio to runable state, once only.
The "doorknob" term came from "everybody gets a turn" and the year was 1970.
Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure
heuristic is the right name for it, but it does point out a
deficieny.
>
A cpu-bound process with many threads will overwhelm a cpu-bound
single threaded threaded process.
>
> A job with many processes will overwhelm a job with a single process.
>
> A user with many jobs can starve a user with a single job.
>
I don't think the problem here is heuristics, rather that the
scheduler's manages cpu quotas at the task level rather than at the
user visible level. If scheduling were managed at all three
hierarchies I mentioned ('job' is a bit artificial, but process and
user are not) then:
>
- if N users are contending for the cpu on a multiuser machine, each
should get just 1/N of available cpu power. As it is, a user can run
a few of your #1 workloads (or a make -j 20) and slow every other
user down - your example would work perfectly (if we can communicate
to the kernel what a job is)
>
> - multi-threaded processes would not get an unfair advantage
If we wanted to do this, a job would be defined as all children or
threads of the oldest parent process with a PPID of one. So if I logged
on and did
make -j4
on a kernel, and someone else did:
find /var -type f | xargs grep -l zumblegarfe
and someone else was doing:
foo & mumble & barfe
We would all be equal. That's good! And there would be some recursive
scheduler which would pick a "job" and then a process, and run it. That
too is good!
But we have a mail server, and there are 671 threads with a socket and
POP3 user on each one, and they only get 1/N of a job worth of CPU
between them, and that sucks rocks off the bottom of the ocean. So
pretty soon the code gets some "fixes" to make POP3 work, and X work,
and the code once again becomes plumber's nightmare... Then you start
playing with process groups to address some of this, and address exec()
corner cases, and complexity goes way up again. This is NOT an easy problem!
I think Con has done a good job, I think in most cases (heresy) the
current mainline scheduler does a pretty good job. I'm in
Re: is RSDL an "unfair" scheduler too?
Con Kolivas wrote: On Saturday 17 March 2007 23:28, Ingo Molnar wrote: * Con Kolivas <[EMAIL PROTECTED]> wrote: We're obviously disagreeing on what heuristics are [...] that could very well be so - it would be helpful if you could provide your own rough definition for the term, so that we can agree on how to call things? [ in any case, there's no rush here, please reply at your own pace, as your condition allows. I wish you a speedy recovery! ] You're simply cashing in on the deep pipes that do kernel work for other tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from rsdl which checks that tasks are waiting on pipes and you're exploiting it. Con, i am not 'cashing in' on anything and i'm not 'exploiting' anything. The TASK_NONINTERACTIVE flag is totally irrelevant to my argument because i was not testing the vanilla scheduler, i was testing RSDL. I could have written this test using plain sockets, because i was testing RSDL's claim of not having heuristics, i was not testing the vanilla scheduler. I have simply replied to this claim of yours: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. [...] and i showed you a workload under _RSDL_ that clearly shows that RSDL is an unfair scheduler too. my whole point was to counter the myth of 'RSDL has no heuristics'. Of course it has heuristics, which results in unfairness. (If it didnt have any heuristics that tilt the balance of scheduling towards sleep-intense tasks then a default Linux desktop would not be usable at all.) so the decision is _not_ a puristic "do we want to have heuristics or not", the question is a more practical "which heuristics are simpler, which heuristics are more flexible, which heuristics result in better behavior". Ingo Ok but please look at how it appears from my end (illness aside). I spend 3 years just diddling with scheduler code trying my hardest to find a design that fixes a whole swag of problems we still have, and a swag of problems we might get with other fixes. You initially said you were pleased with this design. ..lots of code, testing, bugfixes and good feedback. Then Mike has one testcase that most other users disagree is worthy of being considered a regresssion. You latched onto that and basically called it a showstopper in spite of who knows how many other positive things. Then you quickly produce a counter patch designed to kill off RSDL with a config option for mainline. Then you boldly announce on LKML "is RSDL an "unfair" scheduler too?" with some test case you whipped up to try and find fault with the design. No damn it! He's pointing out that you do have heuristics, they are just built into the design. And of course he's whipping up test cases, how else can anyone help you find corner cases where it behaves in an unexpected or undesirable manner? I think he's trying to help, please stop taking it personally. What am I supposed to think? Considering just how many problems I have addressed and tried to correct with RSDL succesfully I'm surprised that despite your enthusiasm for it initially you have spent the rest of the time trying to block it. Please, either help me (and I'm in no shape to code at the moment despite what I have done so far), or say you have no intention of including it. I'm risking paralysis just by sitting at the computer right now so I'm dropping the code as is at the moment and will leave it up to your better judgement as to what to do with it. Actually I think Ingo has tried to help get it in, that's his patch offered for CONFIG_SCHED_FAIR, lets people try it and all. Now for something constructive... by any chance is Mike running KDE instead of GNOME? I only had a short time to play because I had to look at another problem in 2.6.21-rc3 (nbd not working), so the test machine is in use. But it looked as if behavior was not as smooth with KDE. May that thought be useful. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sat, 17 Mar 2007, William Lee Irwin III wrote: > > One issue this raises is prioritizing users on a system, threads within > processes, jobs within users, etc. Doing some "classing" even by just euid might be a good idea. It would actually catch X automatically most of the time, because the euid of the X server is likely to be root, so even for the "trivial" desktop example, it would kind of automatically mean that X would get about 50% of CPU time even if you have a hundred user clients, just because that's "fair" by euid. Dunno. I guess a lot of people would like to then manage the classes, which would be painful as hell. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
> Well, the heuristic here is that process == job. I'm not sure heuristic
> is the right name for it, but it does point out a deficieny.
> A cpu-bound process with many threads will overwhelm a cpu-bound single
> threaded threaded process.
> A job with many processes will overwhelm a job with a single process.
> A user with many jobs can starve a user with a single job.
> I don't think the problem here is heuristics, rather that the
> scheduler's manages cpu quotas at the task level rather than at the user
> visible level. If scheduling were managed at all three hierarchies I
> mentioned ('job' is a bit artificial, but process and user are not) then:
> - if N users are contending for the cpu on a multiuser machine, each
> should get just 1/N of available cpu power. As it is, a user can run a
> few of your #1 workloads (or a make -j 20) and slow every other user down
> - your example would work perfectly (if we can communicate to the kernel
> what a job is)
> - multi-threaded processes would not get an unfair advantage
I like this notion very much. I should probably mention pgrp's' typical
association with the notion of "job," at least as far as shells go.
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc. Maybe sessions would make sense, too,
and classes of users, and maybe whatever they call the affairs that pid
namespaces are a part of (someone will doubtless choke on the hierarchy
depth implied here but it doesn't bother me in the least). It's not a
deep or difficult issue. There just needs to be some user API to set the
relative scheduling priorities of all these affairs within the next higher
level of hierarchy, regardless of how many levels of hierarchy (aleph_0?).
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the design! Let me demonstrate this via a simple experiment.
[...]
But it's easy to demonstrate this under RSDL: consider the following two
scenarios, which implement precisely the same fundamental computing
workload (everything running on the same, default nice 0 level):
1) a single task runs almost all the time and sleeps about 1 msec every
100 msecs.
[ run "while N=1; do N=1; done &" under bash to create such a
workload. ]
2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1
msec and passes the 'token' around to the next task in the ring. (in
essence every task will sleep 9900 msecs before getting another run)
Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time.
They both do in essence the same thing.
if RSDL had no heuristics at all then if i mixed #1 with #2, both
workloads would get roughly 50%/50% of the CPU, right? (as happens if i
mix #1 with #1 - both CPU-intense workloads get half of the CPU)
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound single
threaded threaded process.
A job with many processes will overwhelm a job with a single process.
A user with many jobs can starve a user with a single job.
I don't think the problem here is heuristics, rather that the
scheduler's manages cpu quotas at the task level rather than at the user
visible level. If scheduling were managed at all three hierarchies I
mentioned ('job' is a bit artificial, but process and user are not) then:
- if N users are contending for the cpu on a multiuser machine, each
should get just 1/N of available cpu power. As it is, a user can run a
few of your #1 workloads (or a make -j 20) and slow every other user down
- your example would work perfectly (if we can communicate to the kernel
what a job is)
- multi-threaded processes would not get an unfair advantage
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: is RSDL an "unfair" scheduler too?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of jos poortvliet > Sent: Saturday, March 17, 2007 5:24 AM > To: [EMAIL PROTECTED] > Cc: Con Kolivas; Ingo Molnar; Al Boldi; Mike Galbraith; > linux-kernel@vger.kernel.org; Nicholas Miell; Linus Torvalds; Andrew > Morton > Subject: Re: [ck] Re: is RSDL an "unfair" scheduler too? > > > Op Saturday 17 March 2007, schreef Con Kolivas: > > On Saturday 17 March 2007 22:49, Ingo Molnar wrote: > > > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > > > Despite the claims to the contrary, RSDL does not have _less_ > > > > heuristics, it does not have _any_. It's purely entitlement based. > > > > > > RSDL still has heuristics very much, but this time it's hardcoded into > > > the design! Let me demonstrate this via a simple experiment. > > > > > > in the vanilla scheduler, the heuristics are ontop of a fairly basic > > > (and fast) scheduler, they are plain visible and thus 'optional'. In > > > RSDL, the heuristics are still present but more hidden and more > > > engrained into the design. > > > > > > But it's easy to demonstrate this under RSDL: consider the > following two > > > scenarios, which implement precisely the same fundamental computing > > > workload (everything running on the same, default nice 0 level): > > > > > > 1) a single task runs almost all the time and sleeps about 1 > msec every > > >100 msecs. > > > > > >[ run "while N=1; do N=1; done &" under bash to create such a > > > workload. ] > > > > > > 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 > > >msec and passes the 'token' around to the next task in the > ring. (in > > >essence every task will sleep 9900 msecs before getting > another run) > > > > > >[ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to > > > create this workload. If the 100 tasks default is too > much for you > > > then you can run "./ring-test 10" - that will show > similar effects. > > >] > Well, re-reading his post, he has a point - one WOULD expect each > of these 2 > tasks to have an equal share of CPU, and if RSDL doesn't > currently take this > pipe-thing into account, it might need some fixing. call it > heuristics or not > (after all, how could one NOT say a scheduler uses heuristics of > some kind?). I can't get myself to expect that no matter how hard I try. The scheduler is, by design, fair to *tasks*. So why would one expect two different approaches that do the same thing, but with different numbers of tasks, to each get the same amount of CPU if they compete with each other? One would expect the approach that uses the most tasks to get more CPU. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
* Con Kolivas <[EMAIL PROTECTED]> wrote: > Ok but please look at how it appears from my end (illness aside). ( i really think we should continue this debate after you get better. Everything looks much darker when you are ill! ) > You initially said you were pleased with this design. I said that 2 years ago about the staircase scheduler and i am still saying this about RSDL today. That doesnt make my position automatically correct though :-) For example i wrote and maintained the 4g:4g patchset for over 2 years and still that was no guarantee of it making sense upstream ;) And it was a hell of a lot of work (much uglier and nastier work than any scheduler hacking and tuning, believe me), and it was thrown away as a cute but unnecessary complication we dont need. So what? To me what matters is the path you walk, not the destination you reach. in terms of RSDL design, i like it, still i'm kind of asking myself 'couldnt something in this direction be done in a much simpler and less revolutionary way'? For example couldnt we introduce per-priority level timeslice quotas in the current scheme as well, instead of the very simplistic and crude STARVATION_LIMIT approach? Furthermore, couldnt we make the timeslices become smaller as the runqueue length increases, to make starvation less of a problem? It seems like the problem cases with the current scheduler arent so much centered around the interactivity estimator, it is more that timeslices get distributed too coarsely, while RSDL distributes timeslices in a more finegrained way and is thus less suspect to starvation under certain workloads. in any case, regardless the technical picture, i do get nervous when a group of people tries to out-shout clearly valid feedback like Mike's, and i'll try to balance such effects out a bit. _Of course_ those people that are not happy with the current scheduler have a higher likelyhood to try out another scheduler and be happy about it - but we should not allow that natural bias (which, btw., could easily be the _truth_, so i'm not assuming anything) to stand in the way of critical thinking. I also get slightly nervous about what appears to be dubious technical claims like "this is X's fault and if you rewrite X it will work much better so go away and do not stand in the way of progress" or "this new scheduler does away with all those ugly heuristics". I'm almost getting a reiser4 de ja vu :-/ we should really let this sit through in -mm for at least one more kernel iteration, let more folks be exposed to it and keep an eye on regression reports. [ An _eye_, not a machine gun ;-) ] Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
On Saturday 17 March 2007 23:28, Ingo Molnar wrote: > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > We're obviously disagreeing on what heuristics are [...] > > that could very well be so - it would be helpful if you could provide > your own rough definition for the term, so that we can agree on how to > call things? > > [ in any case, there's no rush here, please reply at your own pace, as > your condition allows. I wish you a speedy recovery! ] > > > You're simply cashing in on the deep pipes that do kernel work for > > other tasks. You know very well that I dropped the TASK_NONINTERACTIVE > > flag from rsdl which checks that tasks are waiting on pipes and you're > > exploiting it. > > Con, i am not 'cashing in' on anything and i'm not 'exploiting' > anything. The TASK_NONINTERACTIVE flag is totally irrelevant to my > argument because i was not testing the vanilla scheduler, i was testing > RSDL. I could have written this test using plain sockets, because i was > testing RSDL's claim of not having heuristics, i was not testing the > vanilla scheduler. > > I have simply replied to this claim of yours: > > > Despite the claims to the contrary, RSDL does not have _less_ > > > heuristics, it does not have _any_. [...] > > and i showed you a workload under _RSDL_ that clearly shows that RSDL is > an unfair scheduler too. > > my whole point was to counter the myth of 'RSDL has no heuristics'. Of > course it has heuristics, which results in unfairness. (If it didnt have > any heuristics that tilt the balance of scheduling towards sleep-intense > tasks then a default Linux desktop would not be usable at all.) > > so the decision is _not_ a puristic "do we want to have heuristics or > not", the question is a more practical "which heuristics are simpler, > which heuristics are more flexible, which heuristics result in better > behavior". > > Ingo Ok but please look at how it appears from my end (illness aside). I spend 3 years just diddling with scheduler code trying my hardest to find a design that fixes a whole swag of problems we still have, and a swag of problems we might get with other fixes. You initially said you were pleased with this design. ..lots of code, testing, bugfixes and good feedback. Then Mike has one testcase that most other users disagree is worthy of being considered a regresssion. You latched onto that and basically called it a showstopper in spite of who knows how many other positive things. Then you quickly produce a counter patch designed to kill off RSDL with a config option for mainline. Then you boldly announce on LKML "is RSDL an "unfair" scheduler too?" with some test case you whipped up to try and find fault with the design. What am I supposed to think? Considering just how many problems I have addressed and tried to correct with RSDL succesfully I'm surprised that despite your enthusiasm for it initially you have spent the rest of the time trying to block it. Please, either help me (and I'm in no shape to code at the moment despite what I have done so far), or say you have no intention of including it. I'm risking paralysis just by sitting at the computer right now so I'm dropping the code as is at the moment and will leave it up to your better judgement as to what to do with it. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
* Con Kolivas <[EMAIL PROTECTED]> wrote: > We're obviously disagreeing on what heuristics are [...] that could very well be so - it would be helpful if you could provide your own rough definition for the term, so that we can agree on how to call things? [ in any case, there's no rush here, please reply at your own pace, as your condition allows. I wish you a speedy recovery! ] > You're simply cashing in on the deep pipes that do kernel work for > other tasks. You know very well that I dropped the TASK_NONINTERACTIVE > flag from rsdl which checks that tasks are waiting on pipes and you're > exploiting it. Con, i am not 'cashing in' on anything and i'm not 'exploiting' anything. The TASK_NONINTERACTIVE flag is totally irrelevant to my argument because i was not testing the vanilla scheduler, i was testing RSDL. I could have written this test using plain sockets, because i was testing RSDL's claim of not having heuristics, i was not testing the vanilla scheduler. I have simply replied to this claim of yours: > > Despite the claims to the contrary, RSDL does not have _less_ > > heuristics, it does not have _any_. [...] and i showed you a workload under _RSDL_ that clearly shows that RSDL is an unfair scheduler too. my whole point was to counter the myth of 'RSDL has no heuristics'. Of course it has heuristics, which results in unfairness. (If it didnt have any heuristics that tilt the balance of scheduling towards sleep-intense tasks then a default Linux desktop would not be usable at all.) so the decision is _not_ a puristic "do we want to have heuristics or not", the question is a more practical "which heuristics are simpler, which heuristics are more flexible, which heuristics result in better behavior". Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an "unfair" scheduler too?
Op Saturday 17 March 2007, schreef Con Kolivas: > On Saturday 17 March 2007 22:49, Ingo Molnar wrote: > > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > > Despite the claims to the contrary, RSDL does not have _less_ > > > heuristics, it does not have _any_. It's purely entitlement based. > > > > RSDL still has heuristics very much, but this time it's hardcoded into > > the design! Let me demonstrate this via a simple experiment. > > > > in the vanilla scheduler, the heuristics are ontop of a fairly basic > > (and fast) scheduler, they are plain visible and thus 'optional'. In > > RSDL, the heuristics are still present but more hidden and more > > engrained into the design. > > > > But it's easy to demonstrate this under RSDL: consider the following two > > scenarios, which implement precisely the same fundamental computing > > workload (everything running on the same, default nice 0 level): > > > > 1) a single task runs almost all the time and sleeps about 1 msec every > >100 msecs. > > > >[ run "while N=1; do N=1; done &" under bash to create such a > > workload. ] > > > > 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 > >msec and passes the 'token' around to the next task in the ring. (in > >essence every task will sleep 9900 msecs before getting another run) > > > >[ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to > > create this workload. If the 100 tasks default is too much for you > > then you can run "./ring-test 10" - that will show similar effects. > >] > > > > Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. > > They both do in essence the same thing. > > > > if RSDL had no heuristics at all then if i mixed #1 with #2, both > > workloads would get roughly 50%/50% of the CPU, right? (as happens if i > > mix #1 with #1 - both CPU-intense workloads get half of the CPU) > > > > in reality, in the 'ring workload' case, RSDL will only give about _5%_ > > of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to > > the #2 'ring' of tasks. So the distribution of timeslices is > > significantly unfair! > > > > Why? Because RSDL still has heuristics, just elsewhere and more hidden: > > in the "straightforward CPU intense task" case RSDL will 'penalize' the > > task by depleting its quota for running nearly all the time, in the > > "ring of tasks" case the 100 tasks will each run near their priority > > maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' > > for seemingly sleeping alot and spreading things out. So RSDL has > > fundamental unfairness built in as well - it's just different from the > > vanilla scheduler. > > We're obviously disagreeing on what heuristics are so call it what you > like. > > You're simply cashing in on the deep pipes that do kernel work for other > tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from > rsdl which checks that tasks are waiting on pipes and you're exploiting it. > That's not the RSDL heuristics at work at all, but you're trying to make it > look like it is the intrinsic RSDL system at work. Putting that flag back > in is simple enough when I'm not drugged. You could have simply pointed > that out instead of trying to make my code look responsible. > > For the moment I'll assume you're not simply trying to make my code look > bad and that you thought there really was an intrinsic design problem, > otherwise I'd really be unhappy with what was happening to me. Well, re-reading his post, he has a point - one WOULD expect each of these 2 tasks to have an equal share of CPU, and if RSDL doesn't currently take this pipe-thing into account, it might need some fixing. call it heuristics or not (after all, how could one NOT say a scheduler uses heuristics of some kind?). Anyway, relax (you know getting angry won't help you getting better) and remember this is email - not exactly a perfet way to communicate, esp in the emotional area. I haven't said this anywhere else, as I'm waiting for RSDL to be a bit more mature, but I have irritations with it as well - I don't have the long full-system stalls I had with staircase (hail RSDL!) but I do have more frequent, shorter stalls, when one app doesn't respond for up to 10 seconds, while others just continue to work. So it's not perfect yet, and when I have time, I'll try to find out what's wrong. BTW, nice seems to help, but not entirely. grtz Jos pgpLhC9CPOAgL.pgp Description: PGP signature
Re: [ck] Re: is RSDL an "unfair" scheduler too?
Op Saturday 17 March 2007, schreef Ingo Molnar: > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > Despite the claims to the contrary, RSDL does not have _less_ > > heuristics, it does not have _any_. It's purely entitlement based. > > RSDL still has heuristics very much, but this time it's hardcoded into > the design! Let me demonstrate this via a simple experiment. > > in the vanilla scheduler, the heuristics are ontop of a fairly basic > (and fast) scheduler, they are plain visible and thus 'optional'. In > RSDL, the heuristics are still present but more hidden and more > engrained into the design. > > But it's easy to demonstrate this under RSDL: consider the following two > scenarios, which implement precisely the same fundamental computing > workload (everything running on the same, default nice 0 level): > > 1) a single task runs almost all the time and sleeps about 1 msec every >100 msecs. > >[ run "while N=1; do N=1; done &" under bash to create such a > workload. ] > > 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 >msec and passes the 'token' around to the next task in the ring. (in >essence every task will sleep 9900 msecs before getting another run) > >[ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to > create this workload. If the 100 tasks default is too much for you > then you can run "./ring-test 10" - that will show similar effects. >] > > Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. > They both do in essence the same thing. > > if RSDL had no heuristics at all then if i mixed #1 with #2, both > workloads would get roughly 50%/50% of the CPU, right? (as happens if i > mix #1 with #1 - both CPU-intense workloads get half of the CPU) Isn't RSDL fair to each task? So each of the 101 tasks (1 and 2) gets an equal share... That doesn't sound unfair to me. if the current scheduler manages to give the single task 10 times more cpu to task one, that wouldn't be fair. Unless you want to be fair to a single process, no matter how many threads. > in reality, in the 'ring workload' case, RSDL will only give about _5%_ > of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to > the #2 'ring' of tasks. So the distribution of timeslices is > significantly unfair! > > Why? Because RSDL still has heuristics, just elsewhere and more hidden: > in the "straightforward CPU intense task" case RSDL will 'penalize' the > task by depleting its quota for running nearly all the time, in the > "ring of tasks" case the 100 tasks will each run near their priority > maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' > for seemingly sleeping alot and spreading things out. So RSDL has > fundamental unfairness built in as well - it's just different from the > vanilla scheduler. I don't see RSDL having heuristics here - it just gives each task an equal share of CPU. The single task gets 1/101th of cpu, equal to all others... > Ingo I guess I just don't get it, would the current kernel give 50% cpu to the single thread, and 0,5% to each of the 100 other threads?!? How would it do that? Does it schedule a process with several threads equal to a process having 1 thread, so each gets an equal share of cpu? pgprhNNkJZYPL.pgp Description: PGP signature
Re: is RSDL an "unfair" scheduler too?
On Saturday 17 March 2007 22:49, Ingo Molnar wrote: > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > Despite the claims to the contrary, RSDL does not have _less_ > > heuristics, it does not have _any_. It's purely entitlement based. > > RSDL still has heuristics very much, but this time it's hardcoded into > the design! Let me demonstrate this via a simple experiment. > > in the vanilla scheduler, the heuristics are ontop of a fairly basic > (and fast) scheduler, they are plain visible and thus 'optional'. In > RSDL, the heuristics are still present but more hidden and more > engrained into the design. > > But it's easy to demonstrate this under RSDL: consider the following two > scenarios, which implement precisely the same fundamental computing > workload (everything running on the same, default nice 0 level): > > 1) a single task runs almost all the time and sleeps about 1 msec every >100 msecs. > >[ run "while N=1; do N=1; done &" under bash to create such a > workload. ] > > 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 >msec and passes the 'token' around to the next task in the ring. (in >essence every task will sleep 9900 msecs before getting another run) > >[ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to > create this workload. If the 100 tasks default is too much for you > then you can run "./ring-test 10" - that will show similar effects. >] > > Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. > They both do in essence the same thing. > > if RSDL had no heuristics at all then if i mixed #1 with #2, both > workloads would get roughly 50%/50% of the CPU, right? (as happens if i > mix #1 with #1 - both CPU-intense workloads get half of the CPU) > > in reality, in the 'ring workload' case, RSDL will only give about _5%_ > of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to > the #2 'ring' of tasks. So the distribution of timeslices is > significantly unfair! > > Why? Because RSDL still has heuristics, just elsewhere and more hidden: > in the "straightforward CPU intense task" case RSDL will 'penalize' the > task by depleting its quota for running nearly all the time, in the > "ring of tasks" case the 100 tasks will each run near their priority > maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' > for seemingly sleeping alot and spreading things out. So RSDL has > fundamental unfairness built in as well - it's just different from the > vanilla scheduler. We're obviously disagreeing on what heuristics are so call it what you like. You're simply cashing in on the deep pipes that do kernel work for other tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from rsdl which checks that tasks are waiting on pipes and you're exploiting it. That's not the RSDL heuristics at work at all, but you're trying to make it look like it is the intrinsic RSDL system at work. Putting that flag back in is simple enough when I'm not drugged. You could have simply pointed that out instead of trying to make my code look responsible. For the moment I'll assume you're not simply trying to make my code look bad and that you thought there really was an intrinsic design problem, otherwise I'd really be unhappy with what was happening to me. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an "unfair" scheduler too?
* Con Kolivas <[EMAIL PROTECTED]> wrote: > Despite the claims to the contrary, RSDL does not have _less_ > heuristics, it does not have _any_. It's purely entitlement based. RSDL still has heuristics very much, but this time it's hardcoded into the design! Let me demonstrate this via a simple experiment. in the vanilla scheduler, the heuristics are ontop of a fairly basic (and fast) scheduler, they are plain visible and thus 'optional'. In RSDL, the heuristics are still present but more hidden and more engrained into the design. But it's easy to demonstrate this under RSDL: consider the following two scenarios, which implement precisely the same fundamental computing workload (everything running on the same, default nice 0 level): 1) a single task runs almost all the time and sleeps about 1 msec every 100 msecs. [ run "while N=1; do N=1; done &" under bash to create such a workload. ] 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 msec and passes the 'token' around to the next task in the ring. (in essence every task will sleep 9900 msecs before getting another run) [ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to create this workload. If the 100 tasks default is too much for you then you can run "./ring-test 10" - that will show similar effects. ] Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. They both do in essence the same thing. if RSDL had no heuristics at all then if i mixed #1 with #2, both workloads would get roughly 50%/50% of the CPU, right? (as happens if i mix #1 with #1 - both CPU-intense workloads get half of the CPU) in reality, in the 'ring workload' case, RSDL will only give about _5%_ of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to the #2 'ring' of tasks. So the distribution of timeslices is significantly unfair! Why? Because RSDL still has heuristics, just elsewhere and more hidden: in the "straightforward CPU intense task" case RSDL will 'penalize' the task by depleting its quota for running nearly all the time, in the "ring of tasks" case the 100 tasks will each run near their priority maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' for seemingly sleeping alot and spreading things out. So RSDL has fundamental unfairness built in as well - it's just different from the vanilla scheduler. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
* Con Kolivas [EMAIL PROTECTED] wrote: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. It's purely entitlement based. RSDL still has heuristics very much, but this time it's hardcoded into the design! Let me demonstrate this via a simple experiment. in the vanilla scheduler, the heuristics are ontop of a fairly basic (and fast) scheduler, they are plain visible and thus 'optional'. In RSDL, the heuristics are still present but more hidden and more engrained into the design. But it's easy to demonstrate this under RSDL: consider the following two scenarios, which implement precisely the same fundamental computing workload (everything running on the same, default nice 0 level): 1) a single task runs almost all the time and sleeps about 1 msec every 100 msecs. [ run while N=1; do N=1; done under bash to create such a workload. ] 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 msec and passes the 'token' around to the next task in the ring. (in essence every task will sleep 9900 msecs before getting another run) [ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to create this workload. If the 100 tasks default is too much for you then you can run ./ring-test 10 - that will show similar effects. ] Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. They both do in essence the same thing. if RSDL had no heuristics at all then if i mixed #1 with #2, both workloads would get roughly 50%/50% of the CPU, right? (as happens if i mix #1 with #1 - both CPU-intense workloads get half of the CPU) in reality, in the 'ring workload' case, RSDL will only give about _5%_ of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to the #2 'ring' of tasks. So the distribution of timeslices is significantly unfair! Why? Because RSDL still has heuristics, just elsewhere and more hidden: in the straightforward CPU intense task case RSDL will 'penalize' the task by depleting its quota for running nearly all the time, in the ring of tasks case the 100 tasks will each run near their priority maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' for seemingly sleeping alot and spreading things out. So RSDL has fundamental unfairness built in as well - it's just different from the vanilla scheduler. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Saturday 17 March 2007 22:49, Ingo Molnar wrote: * Con Kolivas [EMAIL PROTECTED] wrote: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. It's purely entitlement based. RSDL still has heuristics very much, but this time it's hardcoded into the design! Let me demonstrate this via a simple experiment. in the vanilla scheduler, the heuristics are ontop of a fairly basic (and fast) scheduler, they are plain visible and thus 'optional'. In RSDL, the heuristics are still present but more hidden and more engrained into the design. But it's easy to demonstrate this under RSDL: consider the following two scenarios, which implement precisely the same fundamental computing workload (everything running on the same, default nice 0 level): 1) a single task runs almost all the time and sleeps about 1 msec every 100 msecs. [ run while N=1; do N=1; done under bash to create such a workload. ] 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 msec and passes the 'token' around to the next task in the ring. (in essence every task will sleep 9900 msecs before getting another run) [ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to create this workload. If the 100 tasks default is too much for you then you can run ./ring-test 10 - that will show similar effects. ] Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. They both do in essence the same thing. if RSDL had no heuristics at all then if i mixed #1 with #2, both workloads would get roughly 50%/50% of the CPU, right? (as happens if i mix #1 with #1 - both CPU-intense workloads get half of the CPU) in reality, in the 'ring workload' case, RSDL will only give about _5%_ of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to the #2 'ring' of tasks. So the distribution of timeslices is significantly unfair! Why? Because RSDL still has heuristics, just elsewhere and more hidden: in the straightforward CPU intense task case RSDL will 'penalize' the task by depleting its quota for running nearly all the time, in the ring of tasks case the 100 tasks will each run near their priority maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' for seemingly sleeping alot and spreading things out. So RSDL has fundamental unfairness built in as well - it's just different from the vanilla scheduler. We're obviously disagreeing on what heuristics are so call it what you like. You're simply cashing in on the deep pipes that do kernel work for other tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from rsdl which checks that tasks are waiting on pipes and you're exploiting it. That's not the RSDL heuristics at work at all, but you're trying to make it look like it is the intrinsic RSDL system at work. Putting that flag back in is simple enough when I'm not drugged. You could have simply pointed that out instead of trying to make my code look responsible. For the moment I'll assume you're not simply trying to make my code look bad and that you thought there really was an intrinsic design problem, otherwise I'd really be unhappy with what was happening to me. -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an unfair scheduler too?
Op Saturday 17 March 2007, schreef Ingo Molnar: * Con Kolivas [EMAIL PROTECTED] wrote: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. It's purely entitlement based. RSDL still has heuristics very much, but this time it's hardcoded into the design! Let me demonstrate this via a simple experiment. in the vanilla scheduler, the heuristics are ontop of a fairly basic (and fast) scheduler, they are plain visible and thus 'optional'. In RSDL, the heuristics are still present but more hidden and more engrained into the design. But it's easy to demonstrate this under RSDL: consider the following two scenarios, which implement precisely the same fundamental computing workload (everything running on the same, default nice 0 level): 1) a single task runs almost all the time and sleeps about 1 msec every 100 msecs. [ run while N=1; do N=1; done under bash to create such a workload. ] 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 msec and passes the 'token' around to the next task in the ring. (in essence every task will sleep 9900 msecs before getting another run) [ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to create this workload. If the 100 tasks default is too much for you then you can run ./ring-test 10 - that will show similar effects. ] Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. They both do in essence the same thing. if RSDL had no heuristics at all then if i mixed #1 with #2, both workloads would get roughly 50%/50% of the CPU, right? (as happens if i mix #1 with #1 - both CPU-intense workloads get half of the CPU) Isn't RSDL fair to each task? So each of the 101 tasks (1 and 2) gets an equal share... That doesn't sound unfair to me. if the current scheduler manages to give the single task 10 times more cpu to task one, that wouldn't be fair. Unless you want to be fair to a single process, no matter how many threads. in reality, in the 'ring workload' case, RSDL will only give about _5%_ of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to the #2 'ring' of tasks. So the distribution of timeslices is significantly unfair! Why? Because RSDL still has heuristics, just elsewhere and more hidden: in the straightforward CPU intense task case RSDL will 'penalize' the task by depleting its quota for running nearly all the time, in the ring of tasks case the 100 tasks will each run near their priority maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' for seemingly sleeping alot and spreading things out. So RSDL has fundamental unfairness built in as well - it's just different from the vanilla scheduler. I don't see RSDL having heuristics here - it just gives each task an equal share of CPU. The single task gets 1/101th of cpu, equal to all others... Ingo I guess I just don't get it, would the current kernel give 50% cpu to the single thread, and 0,5% to each of the 100 other threads?!? How would it do that? Does it schedule a process with several threads equal to a process having 1 thread, so each gets an equal share of cpu? pgprhNNkJZYPL.pgp Description: PGP signature
Re: [ck] Re: is RSDL an unfair scheduler too?
Op Saturday 17 March 2007, schreef Con Kolivas: On Saturday 17 March 2007 22:49, Ingo Molnar wrote: * Con Kolivas [EMAIL PROTECTED] wrote: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. It's purely entitlement based. RSDL still has heuristics very much, but this time it's hardcoded into the design! Let me demonstrate this via a simple experiment. in the vanilla scheduler, the heuristics are ontop of a fairly basic (and fast) scheduler, they are plain visible and thus 'optional'. In RSDL, the heuristics are still present but more hidden and more engrained into the design. But it's easy to demonstrate this under RSDL: consider the following two scenarios, which implement precisely the same fundamental computing workload (everything running on the same, default nice 0 level): 1) a single task runs almost all the time and sleeps about 1 msec every 100 msecs. [ run while N=1; do N=1; done under bash to create such a workload. ] 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 msec and passes the 'token' around to the next task in the ring. (in essence every task will sleep 9900 msecs before getting another run) [ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to create this workload. If the 100 tasks default is too much for you then you can run ./ring-test 10 - that will show similar effects. ] Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. They both do in essence the same thing. if RSDL had no heuristics at all then if i mixed #1 with #2, both workloads would get roughly 50%/50% of the CPU, right? (as happens if i mix #1 with #1 - both CPU-intense workloads get half of the CPU) in reality, in the 'ring workload' case, RSDL will only give about _5%_ of CPU time to the #1 CPU-intense task, and will give 95% of CPU time to the #2 'ring' of tasks. So the distribution of timeslices is significantly unfair! Why? Because RSDL still has heuristics, just elsewhere and more hidden: in the straightforward CPU intense task case RSDL will 'penalize' the task by depleting its quota for running nearly all the time, in the ring of tasks case the 100 tasks will each run near their priority maximum, fed by 'major epoch' events of RSDL, thus they get 'rewarded' for seemingly sleeping alot and spreading things out. So RSDL has fundamental unfairness built in as well - it's just different from the vanilla scheduler. We're obviously disagreeing on what heuristics are so call it what you like. You're simply cashing in on the deep pipes that do kernel work for other tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from rsdl which checks that tasks are waiting on pipes and you're exploiting it. That's not the RSDL heuristics at work at all, but you're trying to make it look like it is the intrinsic RSDL system at work. Putting that flag back in is simple enough when I'm not drugged. You could have simply pointed that out instead of trying to make my code look responsible. For the moment I'll assume you're not simply trying to make my code look bad and that you thought there really was an intrinsic design problem, otherwise I'd really be unhappy with what was happening to me. Well, re-reading his post, he has a point - one WOULD expect each of these 2 tasks to have an equal share of CPU, and if RSDL doesn't currently take this pipe-thing into account, it might need some fixing. call it heuristics or not (after all, how could one NOT say a scheduler uses heuristics of some kind?). Anyway, relax (you know getting angry won't help you getting better) and remember this is email - not exactly a perfet way to communicate, esp in the emotional area. I haven't said this anywhere else, as I'm waiting for RSDL to be a bit more mature, but I have irritations with it as well - I don't have the long full-system stalls I had with staircase (hail RSDL!) but I do have more frequent, shorter stalls, when one app doesn't respond for up to 10 seconds, while others just continue to work. So it's not perfect yet, and when I have time, I'll try to find out what's wrong. BTW, nice seems to help, but not entirely. grtz Jos pgpLhC9CPOAgL.pgp Description: PGP signature
Re: is RSDL an unfair scheduler too?
* Con Kolivas [EMAIL PROTECTED] wrote: We're obviously disagreeing on what heuristics are [...] that could very well be so - it would be helpful if you could provide your own rough definition for the term, so that we can agree on how to call things? [ in any case, there's no rush here, please reply at your own pace, as your condition allows. I wish you a speedy recovery! ] You're simply cashing in on the deep pipes that do kernel work for other tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from rsdl which checks that tasks are waiting on pipes and you're exploiting it. Con, i am not 'cashing in' on anything and i'm not 'exploiting' anything. The TASK_NONINTERACTIVE flag is totally irrelevant to my argument because i was not testing the vanilla scheduler, i was testing RSDL. I could have written this test using plain sockets, because i was testing RSDL's claim of not having heuristics, i was not testing the vanilla scheduler. I have simply replied to this claim of yours: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. [...] and i showed you a workload under _RSDL_ that clearly shows that RSDL is an unfair scheduler too. my whole point was to counter the myth of 'RSDL has no heuristics'. Of course it has heuristics, which results in unfairness. (If it didnt have any heuristics that tilt the balance of scheduling towards sleep-intense tasks then a default Linux desktop would not be usable at all.) so the decision is _not_ a puristic do we want to have heuristics or not, the question is a more practical which heuristics are simpler, which heuristics are more flexible, which heuristics result in better behavior. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Saturday 17 March 2007 23:28, Ingo Molnar wrote: * Con Kolivas [EMAIL PROTECTED] wrote: We're obviously disagreeing on what heuristics are [...] that could very well be so - it would be helpful if you could provide your own rough definition for the term, so that we can agree on how to call things? [ in any case, there's no rush here, please reply at your own pace, as your condition allows. I wish you a speedy recovery! ] You're simply cashing in on the deep pipes that do kernel work for other tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from rsdl which checks that tasks are waiting on pipes and you're exploiting it. Con, i am not 'cashing in' on anything and i'm not 'exploiting' anything. The TASK_NONINTERACTIVE flag is totally irrelevant to my argument because i was not testing the vanilla scheduler, i was testing RSDL. I could have written this test using plain sockets, because i was testing RSDL's claim of not having heuristics, i was not testing the vanilla scheduler. I have simply replied to this claim of yours: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. [...] and i showed you a workload under _RSDL_ that clearly shows that RSDL is an unfair scheduler too. my whole point was to counter the myth of 'RSDL has no heuristics'. Of course it has heuristics, which results in unfairness. (If it didnt have any heuristics that tilt the balance of scheduling towards sleep-intense tasks then a default Linux desktop would not be usable at all.) so the decision is _not_ a puristic do we want to have heuristics or not, the question is a more practical which heuristics are simpler, which heuristics are more flexible, which heuristics result in better behavior. Ingo Ok but please look at how it appears from my end (illness aside). I spend 3 years just diddling with scheduler code trying my hardest to find a design that fixes a whole swag of problems we still have, and a swag of problems we might get with other fixes. You initially said you were pleased with this design. ..lots of code, testing, bugfixes and good feedback. Then Mike has one testcase that most other users disagree is worthy of being considered a regresssion. You latched onto that and basically called it a showstopper in spite of who knows how many other positive things. Then you quickly produce a counter patch designed to kill off RSDL with a config option for mainline. Then you boldly announce on LKML is RSDL an unfair scheduler too? with some test case you whipped up to try and find fault with the design. What am I supposed to think? Considering just how many problems I have addressed and tried to correct with RSDL succesfully I'm surprised that despite your enthusiasm for it initially you have spent the rest of the time trying to block it. Please, either help me (and I'm in no shape to code at the moment despite what I have done so far), or say you have no intention of including it. I'm risking paralysis just by sitting at the computer right now so I'm dropping the code as is at the moment and will leave it up to your better judgement as to what to do with it. -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
* Con Kolivas [EMAIL PROTECTED] wrote: Ok but please look at how it appears from my end (illness aside). ( i really think we should continue this debate after you get better. Everything looks much darker when you are ill! ) You initially said you were pleased with this design. I said that 2 years ago about the staircase scheduler and i am still saying this about RSDL today. That doesnt make my position automatically correct though :-) For example i wrote and maintained the 4g:4g patchset for over 2 years and still that was no guarantee of it making sense upstream ;) And it was a hell of a lot of work (much uglier and nastier work than any scheduler hacking and tuning, believe me), and it was thrown away as a cute but unnecessary complication we dont need. So what? To me what matters is the path you walk, not the destination you reach. in terms of RSDL design, i like it, still i'm kind of asking myself 'couldnt something in this direction be done in a much simpler and less revolutionary way'? For example couldnt we introduce per-priority level timeslice quotas in the current scheme as well, instead of the very simplistic and crude STARVATION_LIMIT approach? Furthermore, couldnt we make the timeslices become smaller as the runqueue length increases, to make starvation less of a problem? It seems like the problem cases with the current scheduler arent so much centered around the interactivity estimator, it is more that timeslices get distributed too coarsely, while RSDL distributes timeslices in a more finegrained way and is thus less suspect to starvation under certain workloads. in any case, regardless the technical picture, i do get nervous when a group of people tries to out-shout clearly valid feedback like Mike's, and i'll try to balance such effects out a bit. _Of course_ those people that are not happy with the current scheduler have a higher likelyhood to try out another scheduler and be happy about it - but we should not allow that natural bias (which, btw., could easily be the _truth_, so i'm not assuming anything) to stand in the way of critical thinking. I also get slightly nervous about what appears to be dubious technical claims like this is X's fault and if you rewrite X it will work much better so go away and do not stand in the way of progress or this new scheduler does away with all those ugly heuristics. I'm almost getting a reiser4 de ja vu :-/ we should really let this sit through in -mm for at least one more kernel iteration, let more folks be exposed to it and keep an eye on regression reports. [ An _eye_, not a machine gun ;-) ] Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: is RSDL an unfair scheduler too?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of jos poortvliet Sent: Saturday, March 17, 2007 5:24 AM To: [EMAIL PROTECTED] Cc: Con Kolivas; Ingo Molnar; Al Boldi; Mike Galbraith; linux-kernel@vger.kernel.org; Nicholas Miell; Linus Torvalds; Andrew Morton Subject: Re: [ck] Re: is RSDL an unfair scheduler too? Op Saturday 17 March 2007, schreef Con Kolivas: On Saturday 17 March 2007 22:49, Ingo Molnar wrote: * Con Kolivas [EMAIL PROTECTED] wrote: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. It's purely entitlement based. RSDL still has heuristics very much, but this time it's hardcoded into the design! Let me demonstrate this via a simple experiment. in the vanilla scheduler, the heuristics are ontop of a fairly basic (and fast) scheduler, they are plain visible and thus 'optional'. In RSDL, the heuristics are still present but more hidden and more engrained into the design. But it's easy to demonstrate this under RSDL: consider the following two scenarios, which implement precisely the same fundamental computing workload (everything running on the same, default nice 0 level): 1) a single task runs almost all the time and sleeps about 1 msec every 100 msecs. [ run while N=1; do N=1; done under bash to create such a workload. ] 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1 msec and passes the 'token' around to the next task in the ring. (in essence every task will sleep 9900 msecs before getting another run) [ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to create this workload. If the 100 tasks default is too much for you then you can run ./ring-test 10 - that will show similar effects. ] Well, re-reading his post, he has a point - one WOULD expect each of these 2 tasks to have an equal share of CPU, and if RSDL doesn't currently take this pipe-thing into account, it might need some fixing. call it heuristics or not (after all, how could one NOT say a scheduler uses heuristics of some kind?). I can't get myself to expect that no matter how hard I try. The scheduler is, by design, fair to *tasks*. So why would one expect two different approaches that do the same thing, but with different numbers of tasks, to each get the same amount of CPU if they compete with each other? One would expect the approach that uses the most tasks to get more CPU. DS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the design! Let me demonstrate this via a simple experiment.
[...]
But it's easy to demonstrate this under RSDL: consider the following two
scenarios, which implement precisely the same fundamental computing
workload (everything running on the same, default nice 0 level):
1) a single task runs almost all the time and sleeps about 1 msec every
100 msecs.
[ run while N=1; do N=1; done under bash to create such a
workload. ]
2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1
msec and passes the 'token' around to the next task in the ring. (in
essence every task will sleep 9900 msecs before getting another run)
Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time.
They both do in essence the same thing.
if RSDL had no heuristics at all then if i mixed #1 with #2, both
workloads would get roughly 50%/50% of the CPU, right? (as happens if i
mix #1 with #1 - both CPU-intense workloads get half of the CPU)
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound single
threaded threaded process.
A job with many processes will overwhelm a job with a single process.
A user with many jobs can starve a user with a single job.
I don't think the problem here is heuristics, rather that the
scheduler's manages cpu quotas at the task level rather than at the user
visible level. If scheduling were managed at all three hierarchies I
mentioned ('job' is a bit artificial, but process and user are not) then:
- if N users are contending for the cpu on a multiuser machine, each
should get just 1/N of available cpu power. As it is, a user can run a
few of your #1 workloads (or a make -j 20) and slow every other user down
- your example would work perfectly (if we can communicate to the kernel
what a job is)
- multi-threaded processes would not get an unfair advantage
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound single
threaded threaded process.
A job with many processes will overwhelm a job with a single process.
A user with many jobs can starve a user with a single job.
I don't think the problem here is heuristics, rather that the
scheduler's manages cpu quotas at the task level rather than at the user
visible level. If scheduling were managed at all three hierarchies I
mentioned ('job' is a bit artificial, but process and user are not) then:
- if N users are contending for the cpu on a multiuser machine, each
should get just 1/N of available cpu power. As it is, a user can run a
few of your #1 workloads (or a make -j 20) and slow every other user down
- your example would work perfectly (if we can communicate to the kernel
what a job is)
- multi-threaded processes would not get an unfair advantage
I like this notion very much. I should probably mention pgrp's' typical
association with the notion of job, at least as far as shells go.
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc. Maybe sessions would make sense, too,
and classes of users, and maybe whatever they call the affairs that pid
namespaces are a part of (someone will doubtless choke on the hierarchy
depth implied here but it doesn't bother me in the least). It's not a
deep or difficult issue. There just needs to be some user API to set the
relative scheduling priorities of all these affairs within the next higher
level of hierarchy, regardless of how many levels of hierarchy (aleph_0?).
-- wli
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sat, 17 Mar 2007, William Lee Irwin III wrote: One issue this raises is prioritizing users on a system, threads within processes, jobs within users, etc. Doing some classing even by just euid might be a good idea. It would actually catch X automatically most of the time, because the euid of the X server is likely to be root, so even for the trivial desktop example, it would kind of automatically mean that X would get about 50% of CPU time even if you have a hundred user clients, just because that's fair by euid. Dunno. I guess a lot of people would like to then manage the classes, which would be painful as hell. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
Con Kolivas wrote: On Saturday 17 March 2007 23:28, Ingo Molnar wrote: * Con Kolivas [EMAIL PROTECTED] wrote: We're obviously disagreeing on what heuristics are [...] that could very well be so - it would be helpful if you could provide your own rough definition for the term, so that we can agree on how to call things? [ in any case, there's no rush here, please reply at your own pace, as your condition allows. I wish you a speedy recovery! ] You're simply cashing in on the deep pipes that do kernel work for other tasks. You know very well that I dropped the TASK_NONINTERACTIVE flag from rsdl which checks that tasks are waiting on pipes and you're exploiting it. Con, i am not 'cashing in' on anything and i'm not 'exploiting' anything. The TASK_NONINTERACTIVE flag is totally irrelevant to my argument because i was not testing the vanilla scheduler, i was testing RSDL. I could have written this test using plain sockets, because i was testing RSDL's claim of not having heuristics, i was not testing the vanilla scheduler. I have simply replied to this claim of yours: Despite the claims to the contrary, RSDL does not have _less_ heuristics, it does not have _any_. [...] and i showed you a workload under _RSDL_ that clearly shows that RSDL is an unfair scheduler too. my whole point was to counter the myth of 'RSDL has no heuristics'. Of course it has heuristics, which results in unfairness. (If it didnt have any heuristics that tilt the balance of scheduling towards sleep-intense tasks then a default Linux desktop would not be usable at all.) so the decision is _not_ a puristic do we want to have heuristics or not, the question is a more practical which heuristics are simpler, which heuristics are more flexible, which heuristics result in better behavior. Ingo Ok but please look at how it appears from my end (illness aside). I spend 3 years just diddling with scheduler code trying my hardest to find a design that fixes a whole swag of problems we still have, and a swag of problems we might get with other fixes. You initially said you were pleased with this design. ..lots of code, testing, bugfixes and good feedback. Then Mike has one testcase that most other users disagree is worthy of being considered a regresssion. You latched onto that and basically called it a showstopper in spite of who knows how many other positive things. Then you quickly produce a counter patch designed to kill off RSDL with a config option for mainline. Then you boldly announce on LKML is RSDL an unfair scheduler too? with some test case you whipped up to try and find fault with the design. No damn it! He's pointing out that you do have heuristics, they are just built into the design. And of course he's whipping up test cases, how else can anyone help you find corner cases where it behaves in an unexpected or undesirable manner? I think he's trying to help, please stop taking it personally. What am I supposed to think? Considering just how many problems I have addressed and tried to correct with RSDL succesfully I'm surprised that despite your enthusiasm for it initially you have spent the rest of the time trying to block it. Please, either help me (and I'm in no shape to code at the moment despite what I have done so far), or say you have no intention of including it. I'm risking paralysis just by sitting at the computer right now so I'm dropping the code as is at the moment and will leave it up to your better judgement as to what to do with it. Actually I think Ingo has tried to help get it in, that's his patch offered for CONFIG_SCHED_FAIR, lets people try it and all. Now for something constructive... by any chance is Mike running KDE instead of GNOME? I only had a short time to play because I had to look at another problem in 2.6.21-rc3 (nbd not working), so the test machine is in use. But it looked as if behavior was not as smooth with KDE. May that thought be useful. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
You initially said you were pleased with this design.
I said that 2 years ago about the staircase scheduler and i am still
saying this about RSDL today. That doesnt make my position automatically
correct though :-) For example i wrote and maintained the 4g:4g patchset
for over 2 years and still that was no guarantee of it making sense
upstream ;) And it was a hell of a lot of work (much uglier and nastier
work than any scheduler hacking and tuning, believe me), and it was
thrown away as a cute but unnecessary complication we dont need. So
what? To me what matters is the path you walk, not the destination you
reach.
in terms of RSDL design, i like it, still i'm kind of asking myself
'couldnt something in this direction be done in a much simpler and less
revolutionary way'? For example couldnt we introduce per-priority level
timeslice quotas in the current scheme as well, instead of the very
simplistic and crude STARVATION_LIMIT approach? Furthermore, couldnt we
make the timeslices become smaller as the runqueue length increases, to
make starvation less of a problem? It seems like the problem cases with
the current scheduler arent so much centered around the interactivity
estimator, it is more that timeslices get distributed too coarsely,
while RSDL distributes timeslices in a more finegrained way and is thus
less suspect to starvation under certain workloads.
Yes. The doorknob scheduler was a scheduler which worked as follows:
the runnable processes in the system were put in a priority sorted list
and counted. Then the length of one cycle (turn) was divided by the
number of processes and that was the timeslice. In the next version
upper and lower limits were put on the length of a timeslice, so the
system didn't get eaten by context switches under load or be jerky under
light load. That worked fairly well.
Then people got into creating unfairness to address what they thought
were corner cases, the code turned into a plumber's nightmare, and
occasional jackpot cases created occasional (non-reproducible) hangs.
Finally management noted that the peripherals cost three times as much
as the CPU, so jobs doing i/o should run first. That made batch run like
the clappers of hell, and actually didn't do all the bad things you
might expect. User input was waitio, disk was waitio, response was about
as good as it could be for that hardware.
=== it might be useful to give high priority to a process going from
waitio to runable state, once only.
The doorknob term came from everybody gets a turn and the year was 1970.
Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure
heuristic is the right name for it, but it does point out a
deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound
single threaded threaded process.
A job with many processes will overwhelm a job with a single process.
A user with many jobs can starve a user with a single job.
I don't think the problem here is heuristics, rather that the
scheduler's manages cpu quotas at the task level rather than at the
user visible level. If scheduling were managed at all three
hierarchies I mentioned ('job' is a bit artificial, but process and
user are not) then:
- if N users are contending for the cpu on a multiuser machine, each
should get just 1/N of available cpu power. As it is, a user can run
a few of your #1 workloads (or a make -j 20) and slow every other
user down - your example would work perfectly (if we can communicate
to the kernel what a job is)
- multi-threaded processes would not get an unfair advantage
If we wanted to do this, a job would be defined as all children or
threads of the oldest parent process with a PPID of one. So if I logged
on and did
make -j4
on a kernel, and someone else did:
find /var -type f | xargs grep -l zumblegarfe
and someone else was doing:
foo mumble barfe
We would all be equal. That's good! And there would be some recursive
scheduler which would pick a job and then a process, and run it. That
too is good!
But we have a mail server, and there are 671 threads with a socket and
POP3 user on each one, and they only get 1/N of a job worth of CPU
between them, and that sucks rocks off the bottom of the ocean. So
pretty soon the code gets some fixes to make POP3 work, and X work,
and the code once again becomes plumber's nightmare... Then you start
playing with process groups to address some of this, and address exec()
corner cases, and complexity goes way up again. This is NOT an easy problem!
I think Con has done a good job, I think in most cases (heresy) the
current mainline scheduler does a pretty good job. I'm in favor of
having several
Re: is RSDL an unfair scheduler too?
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote: Con Kolivas wrote: snip Now for something constructive... by any chance is Mike running KDE instead of GNOME? I only had a short time to play because I had to look at another problem in 2.6.21-rc3 (nbd not working), so the test machine is in use. But it looked as if behavior was not as smooth with KDE. May that thought be useful. Now i must say here, i use KDE, and have been testing 0.31, and i have been observing all the effects, in contrast with vanilla and staircase. this is on 2.6.20 I do not notice kde being slower, in fact i notice various interactivity speedups compared to mainline. first one i noticed(because i deliberately tested) was kicker. Kickers hide function was very very smooth during boot, and still is under load. It is not entirely as smooth under vanilla during boot(i suspect IO issue), under staircase it is, however under huge loads, it even is not smooth under staircase. then i started my konsole, and the one thing i immediately noticed was that zsh started instantly, usually i can see/(feel) zsh starting, as in it takes like 0.2 before my prompt comes. This is simply gone now with rsdl, behavior used to be the same in vanilla/rsdl. But the most interresting, and dare i say, completely unexpected things are much more important. I have for a long time had issues with tvtime, if i did stuff like move windows, tvtime would drop frames, or simply hovering javascript stuff on sites in konqueror, (this seemed to be introduced in 2.6.~5+), cause in EARLY 2.6 i did not have this problem, but it was the same in staircase and vanilla. But this is gone completely, tvtime no longer drops any frames when doing this. Another thing i noticed, which almost blew my mind as badly as with tvtime, was with wine, and world of warcraft(and nvidia blob driver, but this IS what many desktop users runs). While loading a level, the sound no longer skipped. This problem afaik, EVERYBODY which runs wine +wow has(unless they change the buffer size to ridicoulesly high which annoys gameplay). And more playing wow has shown me that rsdl seems to be doing an extremely good job of not letting other tasks interfere. For example i have spamasassin going quite very often (every minute, for lots of accounts), and this usually kills all sorts of high performance opengl stuff, causing severe stuttering, but with RSDL i only noticed my framerate dropping, but no strange stuttering as i usually experience, only lowered fps, which to me is quite natural, as spamasassin now has to use cpu. the last of my immediate observations are ktorrent. my ktorrent has LOTS of open fd's (in fact like ~5-6k), and the application tends to be very sluggish, but that is not so anymore. And now for the side effects i have observed. The only down right regression (which i wouldnt even call it, cause its a NATURAL thing when other stuff uses cpu) is that when i play a movie in kaffeine, and move the kaffeine window insanely fast all over the desktop, the audio skipped once, the strange thing is, even if i keep moving it, it does not skip any more, only the one time when you start to move it. But 720p h264 does take SOME cpu to decode, so i dont feel that this is unfair. i have however with X observed that under high load(720p h264 video playback, while doing video encoding, ktorrent running, and make running) that windows take longer time to redraw in X, if i move windows over each other, but not really a problem. another effect i have observed is that stuff does not stutter as much when under load, it simply gets slower.(but i suppose thats what i said when describing the good effects i have noticed) it should be noted that i have not reniced a single thing, and this is a singlecore amd64 2ghz with 1.5gb ram. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
William Lee Irwin III wrote:
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound single
threaded threaded process.
A job with many processes will overwhelm a job with a single process.
A user with many jobs can starve a user with a single job.
I don't think the problem here is heuristics, rather that the
scheduler's manages cpu quotas at the task level rather than at the user
visible level. If scheduling were managed at all three hierarchies I
mentioned ('job' is a bit artificial, but process and user are not) then:
- if N users are contending for the cpu on a multiuser machine, each
should get just 1/N of available cpu power. As it is, a user can run a
few of your #1 workloads (or a make -j 20) and slow every other user down
- your example would work perfectly (if we can communicate to the kernel
what a job is)
- multi-threaded processes would not get an unfair advantage
I like this notion very much. I should probably mention pgrp's' typical
association with the notion of job, at least as far as shells go.
One day I might understand what pgrp, sessions, and all that stuff is.
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc. Maybe sessions would make sense, too,
and classes of users, and maybe whatever they call the affairs that pid
namespaces are a part of (someone will doubtless choke on the hierarchy
depth implied here but it doesn't bother me in the least). It's not a
deep or difficult issue. There just needs to be some user API to set the
relative scheduling priorities of all these affairs within the next higher
level of hierarchy, regardless of how many levels of hierarchy (aleph_0?).
I think it follows naturally.
Note that more than the scheduler needs to be taught about this. The
page cache and swapper should prevent a user from swapping out too many
of another user's pages when there is contention for memory; there
should be per-user quotas for network and disk bandwidth, etc. Until
then people who want true multiuser with untrusted users will be forced
to use ugly hacks like virtualization. Fortunately it seems the
container people are addressing at least a part of this.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote: On Sat, 17 Mar 2007, William Lee Irwin III wrote: One issue this raises is prioritizing users on a system, threads within processes, jobs within users, etc. Doing some classing even by just euid might be a good idea. It would actually catch X automatically most of the time, because the euid of the X server is likely to be root, so even for the trivial desktop example, it would kind of automatically mean that X would get about 50% of CPU time even if you have a hundred user clients, just because that's fair by euid. Warning: all these ideas seem interesting for desktop, but are definitely not for servers. I found RSDL to be excellent on servers, compared to mainline in which some services are starving under load. I can understand that on the desktop people want some unfairness, and I like the pgrp idea for instance. But this one will certainly fail on servers, or make the admins get grey hair very soon. Maybe we're all discussing the problem because we have reached the point where we need two types of schedulers : one for the desktop and one for the servers. After all, this is already what is proposed with preempt, it would make sense provided they share the same core and avoid ifdefs or unused structure members. Maybe adding OPTIONAL unfairness to RSDL would help some scenarios, but in any case it is important to retain the default fairness it provides. Dunno. I guess a lot of people would like to then manage the classes, which would be painful as hell. Sure ! I wouldn't like people to point the finger on Linux saying hey look, they can't write a good scheduler so you have to adjust the knobs yourself!. I keep in mind that Solaris' scheduler is very good, both fair and interactive. FreeBSD was good (I haven't tested for a long time). We should manage to get something good for most usages, and optimize later for specific uses. Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote: Now for something constructive... by any chance is Mike running KDE instead of GNOME? Yes. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
Willy Tarreau wrote: On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote: On Sat, 17 Mar 2007, William Lee Irwin III wrote: One issue this raises is prioritizing users on a system, threads within processes, jobs within users, etc. Doing some classing even by just euid might be a good idea. It would actually catch X automatically most of the time, because the euid of the X server is likely to be root, so even for the trivial desktop example, it would kind of automatically mean that X would get about 50% of CPU time even if you have a hundred user clients, just because that's fair by euid. Warning: all these ideas seem interesting for desktop, but are definitely not for servers. I found RSDL to be excellent on servers, compared to mainline in which some services are starving under load. I can understand that on the desktop people want some unfairness, and I like the pgrp idea for instance. But this one will certainly fail on servers, or make the admins get grey hair very soon. I didn't suggest adding any unfairness! I suggested being fair by user/job/process instead of being fair by thread (which is actually unfair as it favors multi threaded processes over single threaded processes). Maybe we're all discussing the problem because we have reached the point where we need two types of schedulers : one for the desktop and one for the servers. After all, this is already what is proposed with preempt, it would make sense provided they share the same core and avoid ifdefs or unused structure members. Maybe adding OPTIONAL unfairness to RSDL would help some scenarios, but in any case it is important to retain the default fairness it provides. I hope not. I think that reducing the timeslice base, combined with renicing X all the way to hell should suffice. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote: Dunno. I guess a lot of people would like to then manage the classes, which would be painful as hell. Sure ! I wouldn't like people to point the finger on Linux saying hey look, they can't write a good scheduler so you have to adjust the knobs yourself!. I keep in mind that Solaris' scheduler is very good, both fair and interactive. FreeBSD was good (I haven't tested for a long time). We should manage to get something good for most usages, and optimize later for specific uses. Like I've said in a previous email, SGI schedulers have an interactive term in addition to the normal nice values. If RSDL ends up being too rigid for desktop use, then this might be a good idea to explore in addition to priority manipulation. However, it hasn't been completely proven that RSDL can't handle desktop loads and that needs to be completely explored first. It certain seems like, from the .jpgs that were posted earlier in the thread regarding mysql performance, that RSDL seems to have improved performance for those set ups so it's not universally the case that it sucks for server loads. The cause of this performance difference has yet to be pinpointed. Also, bandwidth scheduler like this are a new critical development for things like the -rt patch. It would benefit greatly if the RSDL basic mechanisms (RR and deadlines) were to somehow slip into that patch and be used for a more strict -rt based scheduling class. It would be the basis for first-class control over process resource usage and would be a first in Linux or any mainstream kernel. This would be a powerful addition to Linux as a whole and RSDL should not be dismissed without these considerations. If it can somehow be integrated into the kernel with interactivity concerns addressed, then it would be an all out win for the kernel in both these areas. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote: Maybe we're all discussing the problem because we have reached the point where we need two types of schedulers : one for the desktop and one for the servers. After all, this is already what is proposed with preempt, it would make sense provided they share the same core and avoid ifdefs or unused structure members. Maybe adding OPTIONAL unfairness to RSDL would help some scenarios, but in any case it is important to retain the default fairness it provides. Bingo. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote: Like I've said in a previous email, SGI schedulers have an interactive term in addition to the normal nice values. If RSDL ends up being too rigid for desktop use, then this might be a good idea to explore in addition to priority manipulation. I've done that already (ain't perfect yet, maybe never be). The hard part is making it automatic, and not ruining the good side of RSDL in the process. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: is RSDL an unfair scheduler too?
On 3/18/07, Mike Galbraith [EMAIL PROTECTED] wrote: On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote: Maybe we're all discussing the problem because we have reached the point where we need two types of schedulers : one for the desktop and one for the servers. After all, this is already what is proposed with preempt, it would make sense provided they share the same core and avoid ifdefs or unused structure members. Maybe adding OPTIONAL unfairness to RSDL would help some scenarios, but in any case it is important to retain the default fairness it provides. Bingo. Sounds like Staircase's interactive mode switch, except this actually requires writing additional code. The per-user system would also be nice for servers, provided there are CPU/disc IO/swapper/... quotas or priorities at least. All in all, I'd hate to see mldonkey eating 1/3 of CPU time, just because it runs as another user. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
