Re: [ck] Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
Chris Friesen wrote: Mark Glines wrote: One minor question: is it even possible to be completely fair on SMP? For instance, if you have a 2-way SMP box running 3 applications, one of which has 2 threads, will the threaded app have an advantage here? (The current system seems to try to keep each thread on a specific CPU, to reduce cache thrashing, which means threads and processes alike each get 50% of the CPU.) I think the ideal in this case would be to have both threads on one cpu, with the other app on the other cpu. This gives inter-process fairness while minimizing the amount of task migration required. Solving this sort of issue was one of the reasons for the smpnice patches. More interesting is the case of three processes on a 2-cpu system. Do we constantly migrate one of them back and forth to ensure that each of them gets 66% of a cpu? Depends how keen you are on fairness. Unless the process are long term continuously active tasks that never sleep it's probably not an issue as they'll probably move around enough in the long term for them each to get 66% over the long term. Exact load balancing for real work loads (where tasks are coming and going, sleeping and waking semi randomly and over relatively brief periods) is probably unattainable because by the time you've work out the ideal placement of the currently runnable tasks on the available CPUs it's all changed and the solution is invalid. The best you can hope for that change isn't so great as to completely invalidate the solution and the changes you make as a result are an improvement on the current allocation of processes to CPUs. The above probably doesn't hold for some systems such as those large super computer jobs that run for several days but they're probably best served by explicit allocation of processes to CPUs using the process affinity mechanism. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
Mark Glines wrote: One minor question: is it even possible to be completely fair on SMP? For instance, if you have a 2-way SMP box running 3 applications, one of which has 2 threads, will the threaded app have an advantage here? (The current system seems to try to keep each thread on a specific CPU, to reduce cache thrashing, which means threads and processes alike each get 50% of the CPU.) I think the ideal in this case would be to have both threads on one cpu, with the other app on the other cpu. This gives inter-process fairness while minimizing the amount of task migration required. More interesting is the case of three processes on a 2-cpu system. Do we constantly migrate one of them back and forth to ensure that each of them gets 66% of a cpu? Chris - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Wed, 18 Apr 2007 10:22:59 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > So if you have 2 users on a machine running CPU hogs, you should > *first* try to be fair among users. If one user then runs 5 programs, > and the other one runs just 1, then the *one* program should get 50% > of the CPU time (the users fair share), and the five programs should > get 10% of CPU time each. And if one of them uses two threads, each > thread should get 5%. This sounds great, to me. One minor question: is it even possible to be completely fair on SMP? For instance, if you have a 2-way SMP box running 3 applications, one of which has 2 threads, will the threaded app have an advantage here? (The current system seems to try to keep each thread on a specific CPU, to reduce cache thrashing, which means threads and processes alike each get 50% of the CPU.) Mark - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Wed, 18 Apr 2007 10:22:59 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: So if you have 2 users on a machine running CPU hogs, you should *first* try to be fair among users. If one user then runs 5 programs, and the other one runs just 1, then the *one* program should get 50% of the CPU time (the users fair share), and the five programs should get 10% of CPU time each. And if one of them uses two threads, each thread should get 5%. This sounds great, to me. One minor question: is it even possible to be completely fair on SMP? For instance, if you have a 2-way SMP box running 3 applications, one of which has 2 threads, will the threaded app have an advantage here? (The current system seems to try to keep each thread on a specific CPU, to reduce cache thrashing, which means threads and processes alike each get 50% of the CPU.) Mark - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
Mark Glines wrote: One minor question: is it even possible to be completely fair on SMP? For instance, if you have a 2-way SMP box running 3 applications, one of which has 2 threads, will the threaded app have an advantage here? (The current system seems to try to keep each thread on a specific CPU, to reduce cache thrashing, which means threads and processes alike each get 50% of the CPU.) I think the ideal in this case would be to have both threads on one cpu, with the other app on the other cpu. This gives inter-process fairness while minimizing the amount of task migration required. More interesting is the case of three processes on a 2-cpu system. Do we constantly migrate one of them back and forth to ensure that each of them gets 66% of a cpu? Chris - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
Chris Friesen wrote: Mark Glines wrote: One minor question: is it even possible to be completely fair on SMP? For instance, if you have a 2-way SMP box running 3 applications, one of which has 2 threads, will the threaded app have an advantage here? (The current system seems to try to keep each thread on a specific CPU, to reduce cache thrashing, which means threads and processes alike each get 50% of the CPU.) I think the ideal in this case would be to have both threads on one cpu, with the other app on the other cpu. This gives inter-process fairness while minimizing the amount of task migration required. Solving this sort of issue was one of the reasons for the smpnice patches. More interesting is the case of three processes on a 2-cpu system. Do we constantly migrate one of them back and forth to ensure that each of them gets 66% of a cpu? Depends how keen you are on fairness. Unless the process are long term continuously active tasks that never sleep it's probably not an issue as they'll probably move around enough in the long term for them each to get 66% over the long term. Exact load balancing for real work loads (where tasks are coming and going, sleeping and waking semi randomly and over relatively brief periods) is probably unattainable because by the time you've work out the ideal placement of the currently runnable tasks on the available CPUs it's all changed and the solution is invalid. The best you can hope for that change isn't so great as to completely invalidate the solution and the changes you make as a result are an improvement on the current allocation of processes to CPUs. The above probably doesn't hold for some systems such as those large super computer jobs that run for several days but they're probably best served by explicit allocation of processes to CPUs using the process affinity mechanism. Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Mon, Apr 16, 2007 at 03:57:54PM +1000, Matthew Hawkins wrote: > On 4/16/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > > > >So, on to something productive, we have 3 candidates for a new scheduler > >so > >far. How do we decide which way to go? (and yes, I still think switchable > >schedulers is wrong and a copout) > > > I'm with you on that one. It sounds good as a concept however there's > various kernel structures etc that simply cannot be altered at runtime, > which throws away the only advantage I can see of plugsched - a test/debug > framework. > > I think the best way is for those working on this stuff to keep producing > their separate patches against mainline and people being encouraged to > test. THEN > (and here comes the fun part) subsystem maintainers have to be prepared to > accept code that is not their own or that of their IRC buddies. I'm > noticing this disturbing trend that Linux kernel development is becoming > more and more like BSD where only the elite few ever get anywhere. Con > Kolivas, having a medical not CS degree, bruises the egos of those with CS > degrees when he comes up with fairly clean, working, and widely-tested > implementations of things like the staircase scheduler, R(SD)L, SCHED_ISO, > swap prefetch, etc. when they can't. We should be encouraging guys like The thing is, it is really hard for anybody to change anything in page reclaim or CPU scheduler. A few people saying a change is good for them doesn't really mean anything because of the huge amount of diversity in usages. I've got my own CPU scheduler for 4 years and I and a few others think it is better than mainline. I've tried to make many many VM changes that haven't gone in. Add to that, I don't actually know or care what sort of education most kernel hackers have. I do know at least one of the more brilliant ones does not have a CS degree, and I was able to get quite a few things in before I had a degree (eg. rewrote IO scheduler and multiprocessor CPU scheduler). > It's all about the patches, baby I don't know what would give anyone the idea that it isn't... patches and numbers. Nick - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Mon, Apr 16, 2007 at 03:57:54PM +1000, Matthew Hawkins wrote: On 4/16/07, Nick Piggin [EMAIL PROTECTED] wrote: So, on to something productive, we have 3 candidates for a new scheduler so far. How do we decide which way to go? (and yes, I still think switchable schedulers is wrong and a copout) I'm with you on that one. It sounds good as a concept however there's various kernel structures etc that simply cannot be altered at runtime, which throws away the only advantage I can see of plugsched - a test/debug framework. I think the best way is for those working on this stuff to keep producing their separate patches against mainline and people being encouraged to test. THEN (and here comes the fun part) subsystem maintainers have to be prepared to accept code that is not their own or that of their IRC buddies. I'm noticing this disturbing trend that Linux kernel development is becoming more and more like BSD where only the elite few ever get anywhere. Con Kolivas, having a medical not CS degree, bruises the egos of those with CS degrees when he comes up with fairly clean, working, and widely-tested implementations of things like the staircase scheduler, R(SD)L, SCHED_ISO, swap prefetch, etc. when they can't. We should be encouraging guys like The thing is, it is really hard for anybody to change anything in page reclaim or CPU scheduler. A few people saying a change is good for them doesn't really mean anything because of the huge amount of diversity in usages. I've got my own CPU scheduler for 4 years and I and a few others think it is better than mainline. I've tried to make many many VM changes that haven't gone in. Add to that, I don't actually know or care what sort of education most kernel hackers have. I do know at least one of the more brilliant ones does not have a CS degree, and I was able to get quite a few things in before I had a degree (eg. rewrote IO scheduler and multiprocessor CPU scheduler). It's all about the patches, baby I don't know what would give anyone the idea that it isn't... patches and numbers. Nick - 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/
