Am Montag 09 April 2007 schrieb Mike Galbraith:
> On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
> > On Monday 09 April 2007 01:38, Mike Galbraith wrote:
> > > On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
> > > > Hi,
> > > >
> > > > I am one of those who have been happily testing
On Sunday 22 April 2007 20:48, Martin Steigerwald wrote:
> Am Montag 09 April 2007 schrieb Mike Galbraith:
> > On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
> > > On Monday 09 April 2007 01:38, Mike Galbraith wrote:
> > > > On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
> > > > >
On Sunday 22 April 2007 20:48, Martin Steigerwald wrote:
Am Montag 09 April 2007 schrieb Mike Galbraith:
On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
Hi,
I
Am Montag 09 April 2007 schrieb Mike Galbraith:
On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
Hi,
I am one of those who have been happily testing Con's patches.
On Tue, 2007-04-10 at 07:23 -0400, Ed Tomlinson wrote:
> On Monday 09 April 2007 22:39, Mike Galbraith wrote:
> > On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
> >
> > > I don't think you can have very much effect on latency using nice with
> > > SD once the CPU is fully utilized. See
On Monday 09 April 2007 22:39, Mike Galbraith wrote:
> On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
>
> > I don't think you can have very much effect on latency using nice with
> > SD once the CPU is fully utilized. See below.
> >
> > /*
> > * This contains a bitmap for each
On Monday 09 April 2007 22:39, Mike Galbraith wrote:
On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
I don't think you can have very much effect on latency using nice with
SD once the CPU is fully utilized. See below.
/*
* This contains a bitmap for each dynamic priority
On Tue, 2007-04-10 at 07:23 -0400, Ed Tomlinson wrote:
On Monday 09 April 2007 22:39, Mike Galbraith wrote:
On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
I don't think you can have very much effect on latency using nice with
SD once the CPU is fully utilized. See below.
On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
> I don't think you can have very much effect on latency using nice with
> SD once the CPU is fully utilized. See below.
>
> /*
> * This contains a bitmap for each dynamic priority level with empty slots
> * for the valid priorities
On 04/09/2007 03:27 PM, Andreas Mohr wrote:
And I really don't see much difference whatsoever to the I/O scheduler
area: some people want predictable latency, while others want maximum
throughput or fastest operation for seek-less flash devices (noop).
Hardware varies similarly greatly has
On Monday 09 April 2007, Ingo Molnar wrote:[...]
>
>i didnt say that, in fact my first lkml comment about RSDL on lkml was
>the exact opposite, but you SD advocates are _still_ bickering about
>(and not accepting) fundamental things like Mike's make -j5 workload and
>flagging it as unrealistic, so
On 04/09/2007 07:48 PM, Ingo Molnar wrote:
i didnt say that, in fact my first lkml comment about RSDL on lkml
was the exact opposite, but you SD advocates are _still_ bickering
about (and not accepting) fundamental things like Mike's make -j5
workload and flagging it as unrealistic, so until
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> I strongly suggest assembling a battery of cleanly and properly
>> written, configurable testcases, and scripting a series of regression
>> tests as opposed to just randomly running kernel compiles and relying
>> on Braille.
On Mon, Apr 09,
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> I strongly suggest assembling a battery of cleanly and properly
> written, configurable testcases, and scripting a series of regression
> tests as opposed to just randomly running kernel compiles and relying
> on Braille.
there's
On Sat, 2007-04-07 at 20:08 +0200, Ingo Molnar wrote:
>> not many - and i dont think Mike tested any of these - Mike tested
>> pretty low make -j values (Mike, can you confirm?).
On Sat, Apr 07, 2007 at 09:14:21PM +0200, Mike Galbraith wrote:
> Yes. I don't test anything more than make -j5 when
* Rene Herman <[EMAIL PROTECTED]> wrote:
> > - the code actually has to match that stated goal. Right now it
> > diverges from it (it is not a "fair" scheduler), and it's not
> > clear why.
>
> I read most of the discussion centering around that specific point as
> well, and frankly, I
On Mon, 2007-04-09 at 14:14 +0200, Rene Herman wrote:
> This turned into an interactivity thing, and while interactivity is in
> fact better for a large majority of testers, that isn't what Kolivas'
> scheduler is about. It's about predictability and leaving the dead-end
> road of these
On 04/09/2007 04:15 PM, Ingo Molnar wrote:
* Rene Herman <[EMAIL PROTECTED]> wrote:
To me, the example rather serves as confirmation of what Kolivas
has been saying; endlessly tweaking the tweaks isn't going
anywhere.
but ... SD clearly regresses in some areas, so by that logic SD isnt
On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
> On Monday 09 April 2007 01:38, Mike Galbraith wrote:
> > On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
> > > Hi,
> > >
> > > I am one of those who have been happily testing Con's patches.
> > >
> > > They work better than
On 04/09/2007 03:53 PM, Ingo Molnar wrote:
In any case, it would be very nice if you could try Mike's latest
patch, how does it work on your setup? (i've attached it)
Can do. Note that "my setup" in that case consisted of browsing around
eBay in firefox with ogg123 playing audio directly to
* Rene Herman <[EMAIL PROTECTED]> wrote:
> To me, the example rather serves as confirmation of what Kolivas has
> been saying; endlessly tweaking the tweaks isn't going anywhere.
but ... SD clearly regresses in some areas, so by that logic SD isnt
going anywhere either?
note that i still
* Rene Herman <[EMAIL PROTECTED]> wrote:
> > and that change from Mike responded to a testcase. Mike's latest
> > changes (the ones you just tested) were mostly driven by actual
> > testcases too, which measured long-term timeslice distribution
> > fairness.
>
> Ah yes, that one. Here's the
Hi,
On Mon, Apr 09, 2007 at 02:14:49PM +0200, Rene Herman wrote:
> This turned into an interactivity thing, and while interactivity is in
> fact better for a large majority of testers, that isn't what Kolivas'
> scheduler is about. It's about predictability and leaving the dead-end
> road of
On Monday 09 April 2007, Mike Galbraith wrote:
>On Mon, 2007-04-09 at 00:08 -0400, Gene Heskett wrote:
>> On Monday 09 April 2007, Mike Galbraith wrote:
>> >Actually, there was practically nil interest in testing. We made a
>> >couple of minor adjustments to the interactivity logic, and all went
On 04/09/2007 06:23 AM, Mike Galbraith wrote:
On Sun, 2007-04-08 at 20:51 +0200, Rene Herman wrote:
On 04/08/2007 12:41 PM, Ingo Molnar wrote:
commit 5ce74abe788a26698876e66b9c9ce7e7acc25413
Author: Mike Galbraith <[EMAIL PROTECTED]>
Date: Mon Apr 10 22:52:44 2006 -0700
[PATCH]
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
> On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
> > Hi,
> >
> > I am one of those who have been happily testing Con's patches.
> >
> > They work better than mainline here.
>
> (I tried a UP kernel yesterday, and even a single
On Mon, 2007-04-09 at 01:16 -0400, Gene Heskett wrote:
> On Monday 09 April 2007, Mike Galbraith wrote:
> >
> >So tar -cvf - / | gzip --best | tar -tvzf - should reproduce the
> >problem?
> >
> That looks as if it should demo it pretty well if I understand correctly
> everything you're doing
On Mon, 2007-04-09 at 01:23 -0400, Gene Heskett wrote:
> This may not be so informative, its almost behaving ATM.
>
> 29252 amanda22 0 1856 572 220 R 76.4 0.1 1:07.24 gzip
> 29235 amanda15 0 2992 1224 888 S 5.6 0.1 0:02.80 chunker
> 29500 root 18 0 2996 1164 788
On Mon, 2007-04-09 at 01:16 -0400, Gene Heskett wrote:
> On Monday 09 April 2007, Mike Galbraith wrote:
> >So tar -cvf - / | gzip --best | tar -tvzf - should reproduce the
> >problem?
> >
> > -Mike
>
> That looks as if it should demo it pretty well if I understand correctly
> everything
On Mon, 2007-04-09 at 00:08 -0400, Gene Heskett wrote:
> On Monday 09 April 2007, Mike Galbraith wrote:
> >
> >
> >Actually, there was practically nil interest in testing. We made a
> >couple of minor adjustments to the interactivity logic, and all went
> >quiet, so I didn't think it was enough
On Mon, 2007-04-09 at 00:08 -0400, Gene Heskett wrote:
On Monday 09 April 2007, Mike Galbraith wrote:
Actually, there was practically nil interest in testing. We made a
couple of minor adjustments to the interactivity logic, and all went
quiet, so I didn't think it was enough of a problem
On Mon, 2007-04-09 at 01:16 -0400, Gene Heskett wrote:
On Monday 09 April 2007, Mike Galbraith wrote:
So tar -cvf - / | gzip --best | tar -tvzf - should reproduce the
problem?
-Mike
That looks as if it should demo it pretty well if I understand correctly
everything you're doing
On Mon, 2007-04-09 at 01:23 -0400, Gene Heskett wrote:
This may not be so informative, its almost behaving ATM.
29252 amanda22 0 1856 572 220 R 76.4 0.1 1:07.24 gzip
29235 amanda15 0 2992 1224 888 S 5.6 0.1 0:02.80 chunker
29500 root 18 0 2996 1164 788 S
On Mon, 2007-04-09 at 01:16 -0400, Gene Heskett wrote:
On Monday 09 April 2007, Mike Galbraith wrote:
So tar -cvf - / | gzip --best | tar -tvzf - should reproduce the
problem?
That looks as if it should demo it pretty well if I understand correctly
everything you're doing there.
Ok, I
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
Hi,
I am one of those who have been happily testing Con's patches.
They work better than mainline here.
(I tried a UP kernel yesterday, and even a single kernel build would
On 04/09/2007 06:23 AM, Mike Galbraith wrote:
On Sun, 2007-04-08 at 20:51 +0200, Rene Herman wrote:
On 04/08/2007 12:41 PM, Ingo Molnar wrote:
commit 5ce74abe788a26698876e66b9c9ce7e7acc25413
Author: Mike Galbraith [EMAIL PROTECTED]
Date: Mon Apr 10 22:52:44 2006 -0700
[PATCH]
On Monday 09 April 2007, Mike Galbraith wrote:
On Mon, 2007-04-09 at 00:08 -0400, Gene Heskett wrote:
On Monday 09 April 2007, Mike Galbraith wrote:
Actually, there was practically nil interest in testing. We made a
couple of minor adjustments to the interactivity logic, and all went
quiet,
Hi,
On Mon, Apr 09, 2007 at 02:14:49PM +0200, Rene Herman wrote:
This turned into an interactivity thing, and while interactivity is in
fact better for a large majority of testers, that isn't what Kolivas'
scheduler is about. It's about predictability and leaving the dead-end
road of these
* Rene Herman [EMAIL PROTECTED] wrote:
and that change from Mike responded to a testcase. Mike's latest
changes (the ones you just tested) were mostly driven by actual
testcases too, which measured long-term timeslice distribution
fairness.
Ah yes, that one. Here's the next one in
* Rene Herman [EMAIL PROTECTED] wrote:
To me, the example rather serves as confirmation of what Kolivas has
been saying; endlessly tweaking the tweaks isn't going anywhere.
but ... SD clearly regresses in some areas, so by that logic SD isnt
going anywhere either?
note that i still like
On 04/09/2007 03:53 PM, Ingo Molnar wrote:
In any case, it would be very nice if you could try Mike's latest
patch, how does it work on your setup? (i've attached it)
Can do. Note that my setup in that case consisted of browsing around
eBay in firefox with ogg123 playing audio directly to
On Mon, 2007-04-09 at 07:26 -0400, Ed Tomlinson wrote:
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
Hi,
I am one of those who have been happily testing Con's patches.
They work better than mainline here.
(I
On 04/09/2007 04:15 PM, Ingo Molnar wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
To me, the example rather serves as confirmation of what Kolivas
has been saying; endlessly tweaking the tweaks isn't going
anywhere.
but ... SD clearly regresses in some areas, so by that logic SD isnt
going
On Mon, 2007-04-09 at 14:14 +0200, Rene Herman wrote:
This turned into an interactivity thing, and while interactivity is in
fact better for a large majority of testers, that isn't what Kolivas'
scheduler is about. It's about predictability and leaving the dead-end
road of these endlesss
* Rene Herman [EMAIL PROTECTED] wrote:
- the code actually has to match that stated goal. Right now it
diverges from it (it is not a fair scheduler), and it's not
clear why.
I read most of the discussion centering around that specific point as
well, and frankly, I mostly came
On Sat, 2007-04-07 at 20:08 +0200, Ingo Molnar wrote:
not many - and i dont think Mike tested any of these - Mike tested
pretty low make -j values (Mike, can you confirm?).
On Sat, Apr 07, 2007 at 09:14:21PM +0200, Mike Galbraith wrote:
Yes. I don't test anything more than make -j5 when
* William Lee Irwin III [EMAIL PROTECTED] wrote:
I strongly suggest assembling a battery of cleanly and properly
written, configurable testcases, and scripting a series of regression
tests as opposed to just randomly running kernel compiles and relying
on Braille.
there's interbench,
* William Lee Irwin III [EMAIL PROTECTED] wrote:
I strongly suggest assembling a battery of cleanly and properly
written, configurable testcases, and scripting a series of regression
tests as opposed to just randomly running kernel compiles and relying
on Braille.
On Mon, Apr 09, 2007 at
On 04/09/2007 07:48 PM, Ingo Molnar wrote:
i didnt say that, in fact my first lkml comment about RSDL on lkml
was the exact opposite, but you SD advocates are _still_ bickering
about (and not accepting) fundamental things like Mike's make -j5
workload and flagging it as unrealistic, so until
On 04/09/2007 03:27 PM, Andreas Mohr wrote:
And I really don't see much difference whatsoever to the I/O scheduler
area: some people want predictable latency, while others want maximum
throughput or fastest operation for seek-less flash devices (noop).
Hardware varies similarly greatly has
On Monday 09 April 2007, Ingo Molnar wrote:[...]
i didnt say that, in fact my first lkml comment about RSDL on lkml was
the exact opposite, but you SD advocates are _still_ bickering about
(and not accepting) fundamental things like Mike's make -j5 workload and
flagging it as unrealistic, so
On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
I don't think you can have very much effect on latency using nice with
SD once the CPU is fully utilized. See below.
/*
* This contains a bitmap for each dynamic priority level with empty slots
* for the valid priorities each
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
> Hi,
>
> I am one of those who have been happily testing Con's patches.
>
> They work better than mainline here.
(I tried a UP kernel yesterday, and even a single kernel build would
make noticeable hitches if I move a window around. YMMV
On Monday 09 April 2007, Mike Galbraith wrote:
>On Sun, 2007-04-08 at 13:57 -0400, Gene Heskett wrote:
>> On Sunday 08 April 2007, Mike Galbraith wrote:
>> >On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
>> >> On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
>> >> > That seems to
On Monday 09 April 2007, Mike Galbraith wrote:
>On Sun, 2007-04-08 at 13:56 -0400, Gene Heskett wrote:
>> On Sunday 08 April 2007, Mike Galbraith wrote:
>> >On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
>> >> That seems to be the killer loading here, building a kernel (make
>> >> -j3)
On Sun, 2007-04-08 at 20:51 +0200, Rene Herman wrote:
> On 04/08/2007 12:41 PM, Ingo Molnar wrote:
>
> > this is pretty hard to get right, and the most objective way to change
> > it is to do it testcase-driven. FYI, interactivity tweaking has been
> > gradual, the last bigger round of
On Sun, 2007-04-08 at 13:57 -0400, Gene Heskett wrote:
> On Sunday 08 April 2007, Mike Galbraith wrote:
> >On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
> >> On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
> >> > That seems to be the killer loading here, building a kernel (make
>
On Sun, 2007-04-08 at 13:56 -0400, Gene Heskett wrote:
> On Sunday 08 April 2007, Mike Galbraith wrote:
> >On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
> >> That seems to be the killer loading here, building a kernel (make -j3)
> >> doesn't seem to lag it all that bad. One session of
On Monday 09 April 2007, Mike Galbraith wrote:
>On Sun, 2007-04-08 at 13:04 -0400, Gene Heskett wrote:
>> On Sunday 08 April 2007, Ingo Molnar wrote:
>> >and note that a year ago Mike did a larger patch too, not unlike his
>> >current patch - but we hoped that his smaller change would be
>> >
On Sun, 2007-04-08 at 13:04 -0400, Gene Heskett wrote:
> On Sunday 08 April 2007, Ingo Molnar wrote:
> >and note that a year ago Mike did a larger patch too, not unlike his
> >current patch - but we hoped that his smaller change would be sufficient
> >- and nobody came along and said "i tested
On 04/08/2007 12:41 PM, Ingo Molnar wrote:
this is pretty hard to get right, and the most objective way to change
it is to do it testcase-driven. FYI, interactivity tweaking has been
gradual, the last bigger round of interactivity changes were done a year
ago:
commit
On Sunday 08 April 2007, Mike Galbraith wrote:
>On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
>> On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
>> > That seems to be the killer loading here, building a kernel (make
>> > -j3) doesn't seem to lag it all that bad. One session of
On Sunday 08 April 2007, Mike Galbraith wrote:
>On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
>> That seems to be the killer loading here, building a kernel (make -j3)
>> doesn't seem to lag it all that bad. One session of gzip -best makes
>> it fall plumb over though, which was a
On Sunday 08 April 2007, Ingo Molnar wrote:
>* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> > My question then, is why did it take a very public cat-fight to get
>> > this looked at and the code adjusted? Its been what, nearly 2 years
>> > since Linus himself made a comment that this thing needed
Hi,
I am one of those who have been happily testing Con's patches.
They work better than mainline here.
There seems to be a disconnect on what Con is trying to achieve with SD.
They do not improve interactivity per say. Instead they make the scheduler
predictable by removing the alchemy
On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
> On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
>
> > That seems to be the killer loading here, building a kernel (make -j3)
> > doesn't seem to lag it all that bad. One session of gzip -best makes it
> > fall plumb over though,
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
> That seems to be the killer loading here, building a kernel (make -j3)
> doesn't seem to lag it all that bad. One session of gzip -best makes it
> fall plumb over though, which was a disappointment.
Can you make a testcase that doesn't
On Sunday 08 April 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> That said, I am booted to the patch you sent me now, and this also is
>> a very obvious improvement, one I could easily live with on a long
>> term basis. I haven't tried a kernel build in the background
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > My question then, is why did it take a very public cat-fight to get
> > this looked at and the code adjusted? Its been what, nearly 2 years
> > since Linus himself made a comment that this thing needed fixed.
> > The fixes then done were of very
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> That said, I am booted to the patch you sent me now, and this also is
> a very obvious improvement, one I could easily live with on a long
> term basis. I haven't tried a kernel build in the background yet, but
> I have sat here and played patience
* Gene Heskett [EMAIL PROTECTED] wrote:
That said, I am booted to the patch you sent me now, and this also is
a very obvious improvement, one I could easily live with on a long
term basis. I haven't tried a kernel build in the background yet, but
I have sat here and played patience for
* Ingo Molnar [EMAIL PROTECTED] wrote:
My question then, is why did it take a very public cat-fight to get
this looked at and the code adjusted? Its been what, nearly 2 years
since Linus himself made a comment that this thing needed fixed.
The fixes then done were of very little
On Sunday 08 April 2007, Ingo Molnar wrote:
* Gene Heskett [EMAIL PROTECTED] wrote:
That said, I am booted to the patch you sent me now, and this also is
a very obvious improvement, one I could easily live with on a long
term basis. I haven't tried a kernel build in the background yet, but
I
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer loading here, building a kernel (make -j3)
doesn't seem to lag it all that bad. One session of gzip -best makes it
fall plumb over though, which was a disappointment.
Can you make a testcase that doesn't
On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer loading here, building a kernel (make -j3)
doesn't seem to lag it all that bad. One session of gzip -best makes it
fall plumb over though, which
Hi,
I am one of those who have been happily testing Con's patches.
They work better than mainline here.
There seems to be a disconnect on what Con is trying to achieve with SD.
They do not improve interactivity per say. Instead they make the scheduler
predictable by removing the alchemy
On Sunday 08 April 2007, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
My question then, is why did it take a very public cat-fight to get
this looked at and the code adjusted? Its been what, nearly 2 years
since Linus himself made a comment that this thing needed fixed.
The
On Sunday 08 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer loading here, building a kernel (make -j3)
doesn't seem to lag it all that bad. One session of gzip -best makes
it fall plumb over though, which was a
On Sunday 08 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer loading here, building a kernel (make
-j3) doesn't seem to lag it all that bad. One session of gzip -best
On 04/08/2007 12:41 PM, Ingo Molnar wrote:
this is pretty hard to get right, and the most objective way to change
it is to do it testcase-driven. FYI, interactivity tweaking has been
gradual, the last bigger round of interactivity changes were done a year
ago:
commit
On Sun, 2007-04-08 at 13:04 -0400, Gene Heskett wrote:
On Sunday 08 April 2007, Ingo Molnar wrote:
and note that a year ago Mike did a larger patch too, not unlike his
current patch - but we hoped that his smaller change would be sufficient
- and nobody came along and said i tested Mike's and
On Monday 09 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 13:04 -0400, Gene Heskett wrote:
On Sunday 08 April 2007, Ingo Molnar wrote:
and note that a year ago Mike did a larger patch too, not unlike his
current patch - but we hoped that his smaller change would be
sufficient - and
On Sun, 2007-04-08 at 13:56 -0400, Gene Heskett wrote:
On Sunday 08 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer loading here, building a kernel (make -j3)
doesn't seem to lag it all that bad. One session of gzip -best
On Sun, 2007-04-08 at 13:57 -0400, Gene Heskett wrote:
On Sunday 08 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer loading here, building a kernel (make
-j3)
On Sun, 2007-04-08 at 20:51 +0200, Rene Herman wrote:
On 04/08/2007 12:41 PM, Ingo Molnar wrote:
this is pretty hard to get right, and the most objective way to change
it is to do it testcase-driven. FYI, interactivity tweaking has been
gradual, the last bigger round of interactivity
On Monday 09 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 13:56 -0400, Gene Heskett wrote:
On Sunday 08 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer loading here, building a kernel (make
-j3) doesn't seem to
On Monday 09 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 13:57 -0400, Gene Heskett wrote:
On Sunday 08 April 2007, Mike Galbraith wrote:
On Sun, 2007-04-08 at 13:40 +0200, Mike Galbraith wrote:
On Sun, 2007-04-08 at 07:33 -0400, Gene Heskett wrote:
That seems to be the killer
On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
Hi,
I am one of those who have been happily testing Con's patches.
They work better than mainline here.
(I tried a UP kernel yesterday, and even a single kernel build would
make noticeable hitches if I move a window around. YMMV
On Saturday 07 April 2007, Mike Galbraith wrote:
>On Sat, 2007-04-07 at 20:08 +0200, Ingo Molnar wrote:
>> * Gene Heskett <[EMAIL PROTECTED]> wrote:
>> > (who the hell runs a 'make -j 200' or 50 while(1)'s in the real
>> > world?
>>
>> not many - and i dont think Mike tested any of these - Mike
On Saturday 07 April 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> Yes it would be Ingo, but so far, none of the recent -rt patches has
>> booted on this machine, the last one I tried a few days ago failing to
>> find /dev/root, whatever the heck that is.
>
>did you have a
On Sat, 2007-04-07 at 20:08 +0200, Ingo Molnar wrote:
> * Gene Heskett <[EMAIL PROTECTED]> wrote:
> > (who the hell runs a 'make -j 200' or 50 while(1)'s in the real world?
>
> not many - and i dont think Mike tested any of these - Mike tested
> pretty low make -j values (Mike, can you
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> Yes it would be Ingo, but so far, none of the recent -rt patches has
> booted on this machine, the last one I tried a few days ago failing to
> find /dev/root, whatever the heck that is.
did you have a chance to try the yum kernel by any chance? The
On Saturday 07 April 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> To be expected, there are after all, only so many cpu cycles to go
>> around. Here I sit, running 2.6.21-rc6 ATM, and since there is not an
>> SD patch that applies cleanly to rc6, I am back to typing half
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> To be expected, there are after all, only so many cpu cycles to go
> around. Here I sit, running 2.6.21-rc6 ATM, and since there is not an
> SD patch that applies cleanly to rc6, I am back to typing half or more
> of a sentence blind while I answer
On Sat, 2007-04-07 at 16:50 +1000, Con Kolivas wrote:
> On Friday 06 April 2007 20:03, Ingo Molnar wrote:
> > (There was one person who
> > reported wide-scale interactivity regressions against mainline but he
> > didnt answer my followup posts to trace/debug the scenario.)
>
> That was one
On Saturday 07 April 2007, Con Kolivas wrote:
>On Friday 06 April 2007 20:03, Ingo Molnar wrote:
>> * Con Kolivas <[EMAIL PROTECTED]> wrote:
>[...]
>>
>> firstly, testing on various workloads Mike's tweaks work pretty well,
>> while SD still doesnt handle the high-load case all that well. Note
>>
On Friday 06 April 2007 20:03, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > I was more focused on the general case, but all I should have to do
> > > to de-claw all of these sleep exploits is account rr time (only a
> > > couple of lines, done and building now). It's only a
On Friday 06 April 2007 20:03, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
I was more focused on the general case, but all I should have to do
to de-claw all of these sleep exploits is account rr time (only a
couple of lines, done and building now). It's only a couple of
On Saturday 07 April 2007, Con Kolivas wrote:
On Friday 06 April 2007 20:03, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
[...]
firstly, testing on various workloads Mike's tweaks work pretty well,
while SD still doesnt handle the high-load case all that well. Note
that it was
On Sat, 2007-04-07 at 16:50 +1000, Con Kolivas wrote:
On Friday 06 April 2007 20:03, Ingo Molnar wrote:
(There was one person who
reported wide-scale interactivity regressions against mainline but he
didnt answer my followup posts to trace/debug the scenario.)
That was one user. As I
1 - 100 of 117 matches
Mail list logo
