On Sun, 2007-04-15 at 12:58 -0400, Gene Heskett wrote:
Chuckle, possibly but then I'm not anything even remotely close to an expert
here Con, just reporting what I get. And I just rebooted to 2.6.21-rc6 +
sched-mike-5.patch for grins and giggles, or frowns and profanity as the case
may
Hi Ingo,
On Sun, Apr 15, 2007 at 07:55:55PM +0200, Ingo Molnar wrote:
* Willy Tarreau [EMAIL PROTECTED] wrote:
Well, since I merged the fair-fork patch, I cannot reproduce (in fact,
bash forks 1000 processes, then progressively execs scheddos, but it
takes some time). So I'm
+ printk(Fair Scheduler: Copyright (c) 2007 Red Hat, Inc., Ingo
Molnar\n);
So that's what all the fuss about the staircase scheduler is all about
then! At last, I see your point.
i'd like to give credit to Con Kolivas for the general approach here:
he has proven via RSDL/SD
On Apr 15, 2007, at 10:59 AM, Linus Torvalds wrote:
It's a really good thing, and it means that if somebody shows that
your
code is flawed in some way (by, for example, making a patch that
people
claim gets better behaviour or numbers), any *good* programmer that
actually cares about his
* Willy Tarreau [EMAIL PROTECTED] wrote:
to debug this, could you try to apply this add-on as well:
http://redhat.com/~mingo/cfs-scheduler/sched-fair-print.patch
with this patch applied you should have a /proc/sched_debug file
that prints all runnable tasks and other interesting
On Sun, Apr 15, 2007 at 09:20:46PM +0200, Ingo Molnar wrote:
so Linus was right: this was caused by scheduler starvation. I can see
one immediate problem already: the 'nice offset' is not divided by
nr_running as it should. The patch below should fix this but i have yet
to test it
* Ingo Molnar [EMAIL PROTECTED] wrote:
so Linus was right: this was caused by scheduler starvation. I can see
one immediate problem already: the 'nice offset' is not divided by
nr_running as it should. The patch below should fix this but i have
yet to test it accurately, this change might
* William Lee Irwin III [EMAIL PROTECTED] wrote:
On Sun, Apr 15, 2007 at 09:20:46PM +0200, Ingo Molnar wrote:
so Linus was right: this was caused by scheduler starvation. I can
see one immediate problem already: the 'nice offset' is not divided
by nr_running as it should. The patch
On Sun, Apr 15, 2007 at 05:05:36PM +0200, Ingo Molnar wrote:
so the rejection was on these grounds, and i still very much stand by
that position here and today: i didnt want to see the Linux scheduler
landscape balkanized and i saw no technological reasons for the
complication that external
* Matt Mackall [EMAIL PROTECTED] wrote:
Look at what happened with I/O scheduling. Opening things up to some
new ideas by making it possible to select your I/O scheduler took us
from 10 years of stagnation to healthy, competitive development, which
gave us a substantially better I/O
On Sun, Apr 15, 2007 at 10:48:24PM +0200, Ingo Molnar wrote:
* Matt Mackall [EMAIL PROTECTED] wrote:
Look at what happened with I/O scheduling. Opening things up to some
new ideas by making it possible to select your I/O scheduler took us
from 10 years of stagnation to healthy,
On Sun, Apr 15, 2007 at 01:27:13PM +1000, Con Kolivas wrote:
...
> Now that you're agreeing my direction was correct you've done the usual Linux
> kernel thing - ignore all my previous code and write your own version. Oh
> well, that I've come to expect; at least you get a copyright notice in
On Sat, 14 Apr 2007, William Lee Irwin III wrote:
> The two basic attacks on such large priority spaces are the near future
> vs. far future subdivisions and subdividing the priority space into
> (most often regular) intervals. Subdividing the priority space into
> intervals is the most obvious;
On Fri, 13 Apr 2007, William Lee Irwin III wrote:
>> A binomial heap would likely serve your purposes better than rbtrees.
[...]
On Sat, Apr 14, 2007 at 03:38:04PM -0700, Davide Libenzi wrote:
> Haven't looked at the scheduler code yet, but for a similar problem I use
> a time ring. The ring has
On Saturday 14 April 2007 06:21, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
> [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>
On Sat, 14 Apr 2007, Davide Libenzi wrote:
> Haven't looked at the scheduler code yet, but for a similar problem I use
> a time ring. The ring has Ns (2 power is better) slots (where tasks are
> queued - in my case they were som sort of timers), and it has a current
> base index (Ib), a
On Fri, 13 Apr 2007, William Lee Irwin III wrote:
> On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> >The CFS patch uses a completely different approach and implementation
> >from RSDL/SD. My goal was to make CFS's interactivity quality exceed
> >that of RSDL/SD, which
On Sat, Apr 14, 2007 at 12:48:55PM -0700, William Lee Irwin III wrote:
> On Sat, Apr 14, 2007 at 10:36:25AM +0200, Willy Tarreau wrote:
> > Forking becomes very slow above a load of 100 it seems. Sometimes,
> > the shell takes 2 or 3 seconds to return to prompt after I run
> > "scheddos &"
> >
On Sat, Apr 14, 2007 at 10:36:25AM +0200, Willy Tarreau wrote:
> Forking becomes very slow above a load of 100 it seems. Sometimes,
> the shell takes 2 or 3 seconds to return to prompt after I run
> "scheddos &"
> Those are very promising results, I nearly observe the same responsiveness
> as I
On Sat, Apr 14, 2007 at 12:40:15PM -0600, Eric W. Biederman wrote:
> Willy Tarreau <[EMAIL PROTECTED]> writes:
>
> > On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
> >>
> >> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >>
> >> > > Thinking about it, I don't know if there are
On Sat, Apr 14, 2007 at 01:18:09AM +0200, Ingo Molnar wrote:
> very much so! Both Con and Mike has contributed regularly to upstream
> sched.c:
The problem here is tha Con can get demotivated (and rather upset) when an
idea gets proposed, like SchedPlug, only to have people be hostile to it
and
Willy Tarreau <[EMAIL PROTECTED]> writes:
> On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
>>
>> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>
>> > > Thinking about it, I don't know if there are calls to schedule()
>> > > while switching from tty1 to tty2. Alt-F2 had no
On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
>
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > > Thinking about it, I don't know if there are calls to schedule()
> > > while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
> > > "chvt 2" simply blocked. It
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > Thinking about it, I don't know if there are calls to schedule()
> > while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
> > "chvt 2" simply blocked. It would have been possible that a
> > schedule() call somewhere got
On Sat, 14 Apr 2007, Willy Tarreau wrote:
>
> It is clearly possible. What I found strange is that I could still fork
> processes (eg: ls, dmesg|tail), ... but not switch to another VT anymore.
Considering the patches in question, it's almost definitely just a CPU
scheduling problem with
Willy Tarreau <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> [...]
>> >> the ramp up slows down after 700-800 processes, but something very
>> >> strange happens. If I'm under X, I can switch the focus to all xterms
>> >> (the WM is still alive) but all xterms are frozen. On the console,
>> >>
Hi Eric,
[...]
> >> the ramp up slows down after 700-800 processes, but something very
> >> strange happens. If I'm under X, I can switch the focus to all xterms
> >> (the WM is still alive) but all xterms are frozen. On the console,
> >> after one moment I simply cannot switch to another VT
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
>> >
>> > Well, I'll stop heating the room for now as I get out of ideas about how
>> > to defeat it.
>>
>> Ah, I found something nasty.
>> If
14 Nis 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
> hm, could you try to strace it and/or attach gdb to it and figure out
> what's wrong? (perhaps involving the Kaffeine developers too?) As long
> as it's not a kernel level crash i cannot see how the scheduler could
> directly cause this -
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
> >
> > Well, I'll stop heating the room for now as I get out of ideas about how
> > to defeat it.
>
> Ah, I found something nasty.
> If I start large batches of processes like this :
>
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> BTW, I've tried your fork patch. It definitely helps forking because
> it takes below one second to create 4000 processes, then the load
> slowly increases. As you said, the children have to earn their share,
> and I find that it makes it easier to
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> > i'm pleased to announce the first release of the "Modular Scheduler
> > Core and Completely Fair Scheduler [CFS]" patchset:
>
> Currently im using Linus's current git + your extra patches + CFS for
> a while. Kaffeine constantly freezes (and uses
Ingo Molnar wrote:
i kept the 50%/50% rule from the old scheduler, but maybe it's a more
pristine (and smaller/faster) approach to just not give new children any
stats history to begin with. I've implemented an add-on patch that
implements this, you can find it at:
13 Nis 2007 Cum tarihinde, Ingo Molnar şunları yazmıştı:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
> [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
C
On Sat, Apr 14, 2007 at 03:27:32PM +0200, Willy Tarreau wrote:
> On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
> >
> > Well, I'll stop heating the room for now as I get out of ideas about how
> > to defeat it.
>
> Ah, I found something nasty.
> If I start large batches of
On Sat, Apr 14, 2007 at 12:53:39PM +0200, Ingo Molnar wrote:
>
> * Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > Forking becomes very slow above a load of 100 it seems. Sometimes, the
> > shell takes 2 or 3 seconds to return to prompt after I run "scheddos
> > &"
>
> this might be
On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
>
> Well, I'll stop heating the room for now as I get out of ideas about how
> to defeat it.
Ah, I found something nasty.
If I start large batches of processes like this :
$ for i in $(seq 1 1000); do ./scheddos2 4000 4000 & done
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> One other thing, what happens in the case of slow, frequency changing,
> are/or inaccurate clocks .. Is the old sched_clock behavior still
> tolerated?
yeah, good question. Yesterday i did a quick testboot with that too, and
it seemed to behave
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Forking becomes very slow above a load of 100 it seems. Sometimes, the
> shell takes 2 or 3 seconds to return to prompt after I run "scheddos
> &"
this might be changed/impacted by the parent-requeue fix that is in the
updated (for real, promise!
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > this fix is not complete - because the child runqueue is locked
> > here, not the parent's. I've fixed this properly in my tree and have
> > uploaded a new sched-modular+cfs.patch. (the effects of the original
> > bug are mostly harmless, the
On Sat, Apr 14, 2007 at 10:08:34AM +0200, Willy Tarreau wrote:
> On Sat, Apr 14, 2007 at 08:43:34AM +0200, Ingo Molnar wrote:
> >
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > Nick noticed that upon fork we change parent->wait_runtime but we do
> > > not requeue it within the rbtree.
>
On Sat, Apr 14, 2007 at 08:43:34AM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > Nick noticed that upon fork we change parent->wait_runtime but we do
> > not requeue it within the rbtree.
>
> this fix is not complete - because the child runqueue is locked here,
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Nick noticed that upon fork we change parent->wait_runtime but we do
> not requeue it within the rbtree.
this fix is not complete - because the child runqueue is locked here,
not the parent's. I've fixed this properly in my tree and have uploaded
a
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >The CFS patch uses a completely different approach and implementation
> >from RSDL/SD. My goal was to make CFS's interactivity quality exceed
> >that of RSDL/SD, which is a high standard to meet :-) Testing
> >feedback is welcome to
* Nick Piggin [EMAIL PROTECTED] wrote:
The CFS patch uses a completely different approach and implementation
from RSDL/SD. My goal was to make CFS's interactivity quality exceed
that of RSDL/SD, which is a high standard to meet :-) Testing
feedback is welcome to decide this
* Ingo Molnar [EMAIL PROTECTED] wrote:
Nick noticed that upon fork we change parent-wait_runtime but we do
not requeue it within the rbtree.
this fix is not complete - because the child runqueue is locked here,
not the parent's. I've fixed this properly in my tree and have uploaded
a new
On Sat, Apr 14, 2007 at 08:43:34AM +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
Nick noticed that upon fork we change parent-wait_runtime but we do
not requeue it within the rbtree.
this fix is not complete - because the child runqueue is locked here,
not the
On Sat, Apr 14, 2007 at 10:08:34AM +0200, Willy Tarreau wrote:
On Sat, Apr 14, 2007 at 08:43:34AM +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
Nick noticed that upon fork we change parent-wait_runtime but we do
not requeue it within the rbtree.
this fix is
* Willy Tarreau [EMAIL PROTECTED] wrote:
this fix is not complete - because the child runqueue is locked
here, not the parent's. I've fixed this properly in my tree and have
uploaded a new sched-modular+cfs.patch. (the effects of the original
bug are mostly harmless, the rbtree
* Willy Tarreau [EMAIL PROTECTED] wrote:
Forking becomes very slow above a load of 100 it seems. Sometimes, the
shell takes 2 or 3 seconds to return to prompt after I run scheddos
this might be changed/impacted by the parent-requeue fix that is in the
updated (for real, promise! ;)
* Daniel Walker [EMAIL PROTECTED] wrote:
One other thing, what happens in the case of slow, frequency changing,
are/or inaccurate clocks .. Is the old sched_clock behavior still
tolerated?
yeah, good question. Yesterday i did a quick testboot with that too, and
it seemed to behave pretty
On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
Well, I'll stop heating the room for now as I get out of ideas about how
to defeat it.
Ah, I found something nasty.
If I start large batches of processes like this :
$ for i in $(seq 1 1000); do ./scheddos2 4000 4000 done
the
On Sat, Apr 14, 2007 at 12:53:39PM +0200, Ingo Molnar wrote:
* Willy Tarreau [EMAIL PROTECTED] wrote:
Forking becomes very slow above a load of 100 it seems. Sometimes, the
shell takes 2 or 3 seconds to return to prompt after I run scheddos
this might be changed/impacted by the
On Sat, Apr 14, 2007 at 03:27:32PM +0200, Willy Tarreau wrote:
On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
Well, I'll stop heating the room for now as I get out of ideas about how
to defeat it.
Ah, I found something nasty.
If I start large batches of processes like
13 Nis 2007 Cum tarihinde, Ingo Molnar şunları yazmıştı:
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
[CFS]
i'm pleased to announce the first release of the Modular Scheduler Core
and Completely Fair Scheduler [CFS] patchset:
Currently im using Linus's current git
Ingo Molnar wrote:
i kept the 50%/50% rule from the old scheduler, but maybe it's a more
pristine (and smaller/faster) approach to just not give new children any
stats history to begin with. I've implemented an add-on patch that
implements this, you can find it at:
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
i'm pleased to announce the first release of the Modular Scheduler
Core and Completely Fair Scheduler [CFS] patchset:
Currently im using Linus's current git + your extra patches + CFS for
a while. Kaffeine constantly freezes (and uses %80+ CPU
* Willy Tarreau [EMAIL PROTECTED] wrote:
BTW, I've tried your fork patch. It definitely helps forking because
it takes below one second to create 4000 processes, then the load
slowly increases. As you said, the children have to earn their share,
and I find that it makes it easier to
* Willy Tarreau [EMAIL PROTECTED] wrote:
On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
Well, I'll stop heating the room for now as I get out of ideas about how
to defeat it.
Ah, I found something nasty.
If I start large batches of processes like this :
$ for i in
14 Nis 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
hm, could you try to strace it and/or attach gdb to it and figure out
what's wrong? (perhaps involving the Kaffeine developers too?) As long
as it's not a kernel level crash i cannot see how the scheduler could
directly cause this -
Ingo Molnar [EMAIL PROTECTED] writes:
* Willy Tarreau [EMAIL PROTECTED] wrote:
On Sat, Apr 14, 2007 at 03:01:01PM +0200, Willy Tarreau wrote:
Well, I'll stop heating the room for now as I get out of ideas about how
to defeat it.
Ah, I found something nasty.
If I start large batches
Hi Eric,
[...]
the ramp up slows down after 700-800 processes, but something very
strange happens. If I'm under X, I can switch the focus to all xterms
(the WM is still alive) but all xterms are frozen. On the console,
after one moment I simply cannot switch to another VT anymore while
Willy Tarreau [EMAIL PROTECTED] writes:
Hi Eric,
[...]
the ramp up slows down after 700-800 processes, but something very
strange happens. If I'm under X, I can switch the focus to all xterms
(the WM is still alive) but all xterms are frozen. On the console,
after one moment I
On Sat, 14 Apr 2007, Willy Tarreau wrote:
It is clearly possible. What I found strange is that I could still fork
processes (eg: ls, dmesg|tail), ... but not switch to another VT anymore.
Considering the patches in question, it's almost definitely just a CPU
scheduling problem with
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Thinking about it, I don't know if there are calls to schedule()
while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
chvt 2 simply blocked. It would have been possible that a
schedule() call somewhere got starved due to the
On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Thinking about it, I don't know if there are calls to schedule()
while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
chvt 2 simply blocked. It would have been
Willy Tarreau [EMAIL PROTECTED] writes:
On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Thinking about it, I don't know if there are calls to schedule()
while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
On Sat, Apr 14, 2007 at 01:18:09AM +0200, Ingo Molnar wrote:
very much so! Both Con and Mike has contributed regularly to upstream
sched.c:
The problem here is tha Con can get demotivated (and rather upset) when an
idea gets proposed, like SchedPlug, only to have people be hostile to it
and
On Sat, Apr 14, 2007 at 12:40:15PM -0600, Eric W. Biederman wrote:
Willy Tarreau [EMAIL PROTECTED] writes:
On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Thinking about it, I don't know if there are calls to schedule()
On Sat, Apr 14, 2007 at 10:36:25AM +0200, Willy Tarreau wrote:
Forking becomes very slow above a load of 100 it seems. Sometimes,
the shell takes 2 or 3 seconds to return to prompt after I run
scheddos
Those are very promising results, I nearly observe the same responsiveness
as I had on a
On Sat, Apr 14, 2007 at 12:48:55PM -0700, William Lee Irwin III wrote:
On Sat, Apr 14, 2007 at 10:36:25AM +0200, Willy Tarreau wrote:
Forking becomes very slow above a load of 100 it seems. Sometimes,
the shell takes 2 or 3 seconds to return to prompt after I run
scheddos
Those are very
On Fri, 13 Apr 2007, William Lee Irwin III wrote:
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
The CFS patch uses a completely different approach and implementation
from RSDL/SD. My goal was to make CFS's interactivity quality exceed
that of RSDL/SD, which is a
On Sat, 14 Apr 2007, Davide Libenzi wrote:
Haven't looked at the scheduler code yet, but for a similar problem I use
a time ring. The ring has Ns (2 power is better) slots (where tasks are
queued - in my case they were som sort of timers), and it has a current
base index (Ib), a current
On Saturday 14 April 2007 06:21, Ingo Molnar wrote:
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
[CFS]
i'm pleased to announce the first release of the Modular Scheduler Core
and Completely Fair Scheduler [CFS] patchset:
http://redhat.com/~mingo/cfs-scheduler
On Fri, 13 Apr 2007, William Lee Irwin III wrote:
A binomial heap would likely serve your purposes better than rbtrees.
[...]
On Sat, Apr 14, 2007 at 03:38:04PM -0700, Davide Libenzi wrote:
Haven't looked at the scheduler code yet, but for a similar problem I use
a time ring. The ring has Ns
On Sat, 14 Apr 2007, William Lee Irwin III wrote:
The two basic attacks on such large priority spaces are the near future
vs. far future subdivisions and subdividing the priority space into
(most often regular) intervals. Subdividing the priority space into
intervals is the most obvious; you
On Sun, Apr 15, 2007 at 01:27:13PM +1000, Con Kolivas wrote:
...
Now that you're agreeing my direction was correct you've done the usual Linux
kernel thing - ignore all my previous code and write your own version. Oh
well, that I've come to expect; at least you get a copyright notice in the
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
One other thing, what happens in the case of slow, frequency changing,
are/or inaccurate clocks .. Is the old sched_clock behavior still
tolerated?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> Where it gets complex is when the behavior patterns vary, e.g. they're
>> not entirely CPU-bound and their desired in-isolation CPU utilization
>> varies, or when nice levels vary, or both vary. [...]
On Sat, Apr 14, 2007 at 01:44:44AM
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> Where it gets complex is when the behavior patterns vary, e.g. they're
> not entirely CPU-bound and their desired in-isolation CPU utilization
> varies, or when nice levels vary, or both vary. [...]
yes. I tested things like
Ingo Molnar wrote:
* Gabriel C <[EMAIL PROTECTED]> wrote:
as usual, any sort of feedback, bugreports, fixes and suggestions
are more than welcome,
Compile error here.
ah, !CONFIG_SMP. Does the patch below do the trick for you? (I've also
updated the full patch at the
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> A binomial heap would likely serve your purposes better than rbtrees.
>> It's faster to have the next item to dequeue at the root of the tree
>> structure rather than a leaf, for one. There are, of course, other
>> priority queue structures
* Gabriel C <[EMAIL PROTECTED]> wrote:
> > as usual, any sort of feedback, bugreports, fixes and suggestions
> > are more than welcome,
>
> Compile error here.
ah, !CONFIG_SMP. Does the patch below do the trick for you? (I've also
updated the full patch at the cfs-scheduler URL)
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >central tunable:
> >
> > /proc/sys/kernel/sched_granularity_ns
> >
> >which can be used to tune the scheduler from 'desktop' (low
> >latencies) to 'server' (good batching) workloads. It defaults to a
> >setting suitable for
Ingo Molnar wrote:
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
i'm pleased to announce the first release of the "Modular Scheduler Core
and Completely Fair Scheduler [CFS]" patchset:
http://redhat.com/~mingo/cfs-scheduler/sched-modular
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> > [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
> > [CFS]
> > i'm pleased to announce the first release of the "Modular S
On Sat, Apr 14, 2007 at 12:30:17AM +0200, Ingo Molnar wrote:
>
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I'm not in love with the current or other schedulers, so I'm
> > indifferent to this change. However, I was reviewing your release
> > notes and the patch and found myself wonder
Hi Ingo,
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
(...)
>CFS's design is quite radical: it does not use runqueues, it uses a
>time-ordered rbtree to build a 'timeline' of fu
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> I'm not in love with the current or other schedulers, so I'm
> indifferent to this change. However, I was reviewing your release
> notes and the patch and found myself wonder what the logarithmic
> complexity of this new scheduler is .. I assumed
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>http:/
On Fri, 2007-04-13 at 22:21 +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>
Ingo Molnar napisał(a):
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>http://redhat.com/~mingo
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> and even adding all the scheduling modules, the total size impact is
> relatively small:
>
> 18 files changed, 1454 insertions(+), 1133 deletions(-)
>
> most of the increase is due to extensive comments. The kernel size
> impact is in fact a small
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> What I originally did did so for a good reason, which was that it was
> intended to support far more radical reorganizations, for instance,
> things that changed the per-cpu runqueue affairs for gang scheduling.
> I wrote a top-level driver
On Fri, Apr 13, 2007 at 02:21:10PM -0700, William Lee Irwin III wrote:
> On Fri, Apr 13, 2007 at 10:55:45PM +0200, Ingo Molnar wrote:
> > Yeah. Note that there are some subtle but crutial differences between
> > PlugSched (which Con used, and which i opposed in the past) and this
> > approach.
>
On Fri, Apr 13, 2007 at 10:55:45PM +0200, Ingo Molnar wrote:
> Yeah. Note that there are some subtle but crutial differences between
> PlugSched (which Con used, and which i opposed in the past) and this
> approach.
> PlugSched cuts the interfaces at a high level in a monolithic way and
>
* Bill Huey <[EMAIL PROTECTED]> wrote:
> Con has been asking for module support for years if I understand your
> patch corectly. [...]
Yeah. Note that there are some subtle but crutial differences between
PlugSched (which Con used, and which i opposed in the past) and this
approach.
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
...
>The CFS patch uses a completely different approach and implementation
>from RSDL/SD. My goal was to make CFS's interactivity quali
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
i'm pleased to announce the first release of the "Modular Scheduler Core
and Completely Fair Scheduler [CFS]" patchset:
http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch
This project is
501 - 600 of 623 matches
Mail list logo
