Antonio Vargas wrote:
IIRC, about 2 or three years ago (or maybe on the 2.6.10 timeframe),
there was a patch which managed to pass the interactive from one app
to another when there was a pipe or udp connection between them. This
meant that a marked-as-interactive xterm would, when blocked
Antonio Vargas wrote:
IIRC, about 2 or three years ago (or maybe on the 2.6.10 timeframe),
there was a patch which managed to pass the interactive from one app
to another when there was a pipe or udp connection between them. This
meant that a marked-as-interactive xterm would, when blocked
Op Sunday 18 March 2007, schreef Con Kolivas:
> On Monday 12 March 2007 22:26, Al Boldi wrote:
> > Con Kolivas wrote:
> > > On Monday 12 March 2007 15:42, Al Boldi wrote:
> > > > Con Kolivas wrote:
> > > > > On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > > > > > And thank you! I think I
Op Sunday 18 March 2007, schreef Con Kolivas:
On Monday 12 March 2007 22:26, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on
Con Kolivas wrote:
On Monday 12 March 2007 22:26, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each
rotation is followed by
Con Kolivas wrote:
On Monday 12 March 2007 22:26, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each
rotation is followed by
On 3/12/07, jos poortvliet <[EMAIL PROTECTED]> wrote:
Op Monday 12 March 2007, schreef Con Kolivas:
> On Tuesday 13 March 2007 01:14, Al Boldi wrote:
> > Con Kolivas wrote:
> > > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > > one runs 6-7ms and then one larger
Op Monday 12 March 2007, schreef Con Kolivas:
> On Tuesday 13 March 2007 01:14, Al Boldi wrote:
> > Con Kolivas wrote:
> > > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > > one runs 6-7ms and then one larger perfectly bound expiration
> > > > > amount. Basically
On Tuesday 13 March 2007 01:14, Al Boldi wrote:
> Con Kolivas wrote:
> > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > one runs 6-7ms and then one larger perfectly bound expiration amount.
> > > > Basically exactly as I'd expect. The higher priority task gets
> >
jos poortvliet wrote:
> > It only takes one negatively nice'd proc to affect X adversely.
>
> Then, maybe, we should start nicing X again, like we did/had to do until a
> few years ago? Or should we just wait until X gets fixed (after all,
> development goes faster than ever)? Or is this really
On 3/12/07, jos poortvliet <[EMAIL PROTECTED]> wrote:
Op Monday 12 March 2007, schreef Al Boldi:
>
> It only takes one negatively nice'd proc to affect X adversely.
goes faster than ever)? Or is this really the scheduler's fault?
Take this with a grain of salt, but, I don't think this is the
Op Monday 12 March 2007, schreef Al Boldi:
> Con Kolivas wrote:
> > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > one runs 6-7ms and then one larger perfectly bound expiration amount.
> > > > Basically exactly as I'd expect. The higher priority task gets
> > > >
Con Kolivas wrote:
> > > The higher priority one always get 6-7ms whereas the lower priority
> > > one runs 6-7ms and then one larger perfectly bound expiration amount.
> > > Basically exactly as I'd expect. The higher priority task gets
> > > precisely RR_INTERVAL maximum latency whereas the
On Monday 12 March 2007 22:26, Al Boldi wrote:
> Con Kolivas wrote:
> > On Monday 12 March 2007 15:42, Al Boldi wrote:
> > > Con Kolivas wrote:
> > > > On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > > > > And thank you! I think I know what's going on now. I think each
> > > > > rotation is
Con Kolivas wrote:
> On Monday 12 March 2007 15:42, Al Boldi wrote:
> > Con Kolivas wrote:
> > > On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > > > And thank you! I think I know what's going on now. I think each
> > > > rotation is followed by another rotation before the higher priority
> >
Con Kolivas wrote:
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each
rotation is followed by another rotation before the higher priority
task is
On Monday 12 March 2007 22:26, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each
rotation is followed by another
Con Kolivas wrote:
The higher priority one always get 6-7ms whereas the lower priority
one runs 6-7ms and then one larger perfectly bound expiration amount.
Basically exactly as I'd expect. The higher priority task gets
precisely RR_INTERVAL maximum latency whereas the lower priority
Op Monday 12 March 2007, schreef Al Boldi:
Con Kolivas wrote:
The higher priority one always get 6-7ms whereas the lower priority
one runs 6-7ms and then one larger perfectly bound expiration amount.
Basically exactly as I'd expect. The higher priority task gets
precisely
On 3/12/07, jos poortvliet [EMAIL PROTECTED] wrote:
Op Monday 12 March 2007, schreef Al Boldi:
It only takes one negatively nice'd proc to affect X adversely.
goes faster than ever)? Or is this really the scheduler's fault?
Take this with a grain of salt, but, I don't think this is the
jos poortvliet wrote:
It only takes one negatively nice'd proc to affect X adversely.
Then, maybe, we should start nicing X again, like we did/had to do until a
few years ago? Or should we just wait until X gets fixed (after all,
development goes faster than ever)? Or is this really the
On Tuesday 13 March 2007 01:14, Al Boldi wrote:
Con Kolivas wrote:
The higher priority one always get 6-7ms whereas the lower priority
one runs 6-7ms and then one larger perfectly bound expiration amount.
Basically exactly as I'd expect. The higher priority task gets
precisely
Op Monday 12 March 2007, schreef Con Kolivas:
On Tuesday 13 March 2007 01:14, Al Boldi wrote:
Con Kolivas wrote:
The higher priority one always get 6-7ms whereas the lower priority
one runs 6-7ms and then one larger perfectly bound expiration
amount. Basically exactly as I'd
On 3/12/07, jos poortvliet [EMAIL PROTECTED] wrote:
Op Monday 12 March 2007, schreef Con Kolivas:
On Tuesday 13 March 2007 01:14, Al Boldi wrote:
Con Kolivas wrote:
The higher priority one always get 6-7ms whereas the lower priority
one runs 6-7ms and then one larger perfectly bound
On Monday 12 March 2007 15:42, Al Boldi wrote:
> Con Kolivas wrote:
> > On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > > And thank you! I think I know what's going on now. I think each
> > > rotation is followed by another rotation before the higher priority
> > > task is getting a look in
Con Kolivas wrote:
> On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > And thank you! I think I know what's going on now. I think each rotation
> > is followed by another rotation before the higher priority task is
> > getting a look in in schedule() to even get quota and add it to the
> >
On Monday 12 March 2007 09:29, bert hubert wrote:
> Con,
>
> Recent kernel versions have real problems for me on the interactivity
> front, with even a simple 'make' of my C++ program (PowerDNS) causing
> Firefox to slow down to a crawl.
>
> RSDL fixed all that, the system is noticeably snappier.
Con,
Recent kernel versions have real problems for me on the interactivity front,
with even a simple 'make' of my C++ program (PowerDNS) causing Firefox to
slow down to a crawl.
RSDL fixed all that, the system is noticeably snappier.
As a case in point, I used to notice when a compile was done
On Monday 12 March 2007 08:52, Con Kolivas wrote:
> And thank you! I think I know what's going on now. I think each rotation is
> followed by another rotation before the higher priority task is getting a
> look in in schedule() to even get quota and add it to the runqueue quota.
> I'll try a
On Monday 12 March 2007 05:11, Al Boldi wrote:
> Al Boldi wrote:
> > BTW, another way to show these hickups would be through some kind of a
> > cpu/proc timing-tracer. Do we have something like that?
>
> Here is something like a tracer.
>
> Original idea by Chris Friesen, thanks, from this post:
Al Boldi wrote:
> BTW, another way to show these hickups would be through some kind of a
> cpu/proc timing-tracer. Do we have something like that?
Here is something like a tracer.
Original idea by Chris Friesen, thanks, from this post:
Al Boldi wrote:
BTW, another way to show these hickups would be through some kind of a
cpu/proc timing-tracer. Do we have something like that?
Here is something like a tracer.
Original idea by Chris Friesen, thanks, from this post:
On Monday 12 March 2007 05:11, Al Boldi wrote:
Al Boldi wrote:
BTW, another way to show these hickups would be through some kind of a
cpu/proc timing-tracer. Do we have something like that?
Here is something like a tracer.
Original idea by Chris Friesen, thanks, from this post:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each rotation is
followed by another rotation before the higher priority task is getting a
look in in schedule() to even get quota and add it to the runqueue quota.
I'll try a simple
Con,
Recent kernel versions have real problems for me on the interactivity front,
with even a simple 'make' of my C++ program (PowerDNS) causing Firefox to
slow down to a crawl.
RSDL fixed all that, the system is noticeably snappier.
As a case in point, I used to notice when a compile was done
On Monday 12 March 2007 09:29, bert hubert wrote:
Con,
Recent kernel versions have real problems for me on the interactivity
front, with even a simple 'make' of my C++ program (PowerDNS) causing
Firefox to slow down to a crawl.
RSDL fixed all that, the system is noticeably snappier.
As a
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each rotation
is followed by another rotation before the higher priority task is
getting a look in in schedule() to even get quota and add it to the
runqueue
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each
rotation is followed by another rotation before the higher priority
task is getting a look in in
On Fri, 9 Mar 2007, Bill Davidsen wrote:
>
> But it IS okay for people to make special-case schedulers. Because it's MY
> machine,
Sure.
Go wild. It's what open-source is all about.
I'm not stopping you.
I'm just not merging code that makes the scheduler unreadable, even hard
to understand,
Linus Torvalds wrote:
On Thu, 8 Mar 2007, Bill Davidsen wrote:
Please, could you now rethink plugable scheduler as well? Even if one had to
be chosen at boot time and couldn't be change thereafter, it would still allow
a few new thoughts to be included.
No. Really.
I absolutely
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
> No. Really.
> I absolutely *detest* pluggable schedulers. They have a huge downside:
> they allow people to think that it's ok to make special-case schedulers.
> And I simply very fundamentally disagree.
> If you want to play with
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
No. Really.
I absolutely *detest* pluggable schedulers. They have a huge downside:
they allow people to think that it's ok to make special-case schedulers.
And I simply very fundamentally disagree.
If you want to play with a
Linus Torvalds wrote:
On Thu, 8 Mar 2007, Bill Davidsen wrote:
Please, could you now rethink plugable scheduler as well? Even if one had to
be chosen at boot time and couldn't be change thereafter, it would still allow
a few new thoughts to be included.
No. Really.
I absolutely
On Fri, 9 Mar 2007, Bill Davidsen wrote:
But it IS okay for people to make special-case schedulers. Because it's MY
machine,
Sure.
Go wild. It's what open-source is all about.
I'm not stopping you.
I'm just not merging code that makes the scheduler unreadable, even hard
to understand,
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
> On Thu, 8 Mar 2007, Bill Davidsen wrote:
> > Please, could you now rethink plugable scheduler as well? Even if one had to
> > be chosen at boot time and couldn't be change thereafter, it would still
> > allow
> > a few new thoughts
On Thu, 8 Mar 2007, Bill Davidsen wrote:
>
> Please, could you now rethink plugable scheduler as well? Even if one had to
> be chosen at boot time and couldn't be change thereafter, it would still allow
> a few new thoughts to be included.
No. Really.
I absolutely *detest* pluggable
Con Kolivas wrote:
On Wednesday 07 March 2007 04:50, Bill Davidsen wrote:
With luck I'll get to shake out that patch in combination with kvm later
today.
Great thanks!. I've appreciated all the feedback so far.
I did try, the 2.6.21-rc3-git3 doesn't want to kvm for me, and your
patch may
Linus Torvalds wrote:
On Mon, 5 Mar 2007, Ed Tomlinson wrote:
The patch _does_ make a difference. For instance reading mail with freenet working
hard (threaded java application) and gentoo's emerge triggering compiles to update the
box is much smoother.
Think this scheduler needs serious
Well, downloaded - compiled - booted: initng measures 17.369 seconds
to complete the boot process; without the patch the same kernel booted
in 21.553 seconds.
Very impressive.
Many thanks for your work.
Fabio
On 3/8/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Friday 09 March 2007
On Friday 09 March 2007 07:25, Fabio Comolli wrote:
> Hi Con
> It would be nice if you could rebase this patch to latest git or at
> least to 2.6.21-rc3.
> Regards,
Check in http://ck.kolivas.org/patches/staircase-deadline/
There's an -rc3 patch there.
--
-ck
-
To unsubscribe from this list:
Hi Con
It would be nice if you could rebase this patch to latest git or at
least to 2.6.21-rc3.
Regards,
Fabio
On 3/4/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
This message is to announce the first general public release of the "Rotating
Staircase DeadLine" cpu scheduler.
Based on previous
Hi Con
Just also wanted to throw in my less than two cents: I applied the patch
and also have the very strong subjective impression that my system
"feels" much more responsive than with stock 2.6.20.
Thanks for the great work.
Bye
Tim
-
To unsubscribe from this list: send the line
On Thursday 08 March 2007 19:53, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > This message is to announce the first general public release of the
> > "Rotating Staircase DeadLine" cpu scheduler.
> >
> > Based on previous work from the staircase cpu scheduler I set out to
> >
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> This message is to announce the first general public release of the
> "Rotating Staircase DeadLine" cpu scheduler.
>
> Based on previous work from the staircase cpu scheduler I set out to
> design, from scratch, a new scheduling policy design which
Hi Con
Just also wanted to throw in my less than two cents: I applied the patch
and also have the very strong subjective impression that my system
feels much more responsive than with stock 2.6.20.
Thanks for the great work.
Bye
Tim
-
To unsubscribe from this list: send the line unsubscribe
Hi Con
It would be nice if you could rebase this patch to latest git or at
least to 2.6.21-rc3.
Regards,
Fabio
On 3/4/07, Con Kolivas [EMAIL PROTECTED] wrote:
This message is to announce the first general public release of the Rotating
Staircase DeadLine cpu scheduler.
Based on previous
On Friday 09 March 2007 07:25, Fabio Comolli wrote:
Hi Con
It would be nice if you could rebase this patch to latest git or at
least to 2.6.21-rc3.
Regards,
Check in http://ck.kolivas.org/patches/staircase-deadline/
There's an -rc3 patch there.
--
-ck
-
To unsubscribe from this list: send
Well, downloaded - compiled - booted: initng measures 17.369 seconds
to complete the boot process; without the patch the same kernel booted
in 21.553 seconds.
Very impressive.
Many thanks for your work.
Fabio
On 3/8/07, Con Kolivas [EMAIL PROTECTED] wrote:
On Friday 09 March 2007 07:25,
Linus Torvalds wrote:
On Mon, 5 Mar 2007, Ed Tomlinson wrote:
The patch _does_ make a difference. For instance reading mail with freenet working
hard (threaded java application) and gentoo's emerge triggering compiles to update the
box is much smoother.
Think this scheduler needs serious
Con Kolivas wrote:
On Wednesday 07 March 2007 04:50, Bill Davidsen wrote:
With luck I'll get to shake out that patch in combination with kvm later
today.
Great thanks!. I've appreciated all the feedback so far.
I did try, the 2.6.21-rc3-git3 doesn't want to kvm for me, and your
patch may
On Thu, 8 Mar 2007, Bill Davidsen wrote:
Please, could you now rethink plugable scheduler as well? Even if one had to
be chosen at boot time and couldn't be change thereafter, it would still allow
a few new thoughts to be included.
No. Really.
I absolutely *detest* pluggable schedulers.
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
On Thu, 8 Mar 2007, Bill Davidsen wrote:
Please, could you now rethink plugable scheduler as well? Even if one had to
be chosen at boot time and couldn't be change thereafter, it would still
allow
a few new thoughts to be
* Con Kolivas [EMAIL PROTECTED] wrote:
This message is to announce the first general public release of the
Rotating Staircase DeadLine cpu scheduler.
Based on previous work from the staircase cpu scheduler I set out to
design, from scratch, a new scheduling policy design which satisfies
On Thursday 08 March 2007 19:53, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
This message is to announce the first general public release of the
Rotating Staircase DeadLine cpu scheduler.
Based on previous work from the staircase cpu scheduler I set out to
design, from
Hi Bill,
On Tue, Mar 06, 2007 at 04:37:37PM -0500, Bill Davidsen wrote:
(...)
> The point is that no one CPU scheduler will satisfy the policy needs of
> all users, any more than one i/o scheduler does so. We have realtime
> scheduling, preempt both voluntary and involuntary, why should we not
Willy Tarreau wrote:
On Tue, Mar 06, 2007 at 11:18:44AM +1100, Con Kolivas wrote:
On Tuesday 06 March 2007 10:05, Bill Davidsen wrote:
jos poortvliet wrote:
Well, imho his current staircase scheduler already does a better job
compared to mainline, but it won't make it in (or at
On Wednesday 07 March 2007 04:50, Bill Davidsen wrote:
> Gene Heskett wrote:
> > On Monday 05 March 2007, Nicolas Mailhot wrote:
> >> This looks like -mm stuff if you want it in 2.6.22
> >
> > This needs to get to 2.6.21, it really is that big an improvement.
>
> As Con pointed out, for some
Op Tuesday 06 March 2007, schreef Willy Tarreau:
> In a way, I think they are right. Let me explain. Pluggable schedulers are
> useful when you want to switch away from the default one. This is very
> useful during development of a new scheduler, as well as when you're not
> satisfied with the
Gene Heskett wrote:
On Monday 05 March 2007, Nicolas Mailhot wrote:
This looks like -mm stuff if you want it in 2.6.22
This needs to get to 2.6.21, it really is that big an improvement.
As Con pointed out, for some workloads and desired behavour this is not
as good as the existing
Xavier Bestel wrote:
> On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
> > Hah I just wish gears would go away. If I get hardware where it runs at
> > just the right speed it looks like it doesn't move at all. On other
> > hardware the wheels go backwards and forwards where the screen
On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
> Hah I just wish gears would go away. If I get hardware where it runs at just
> the right speed it looks like it doesn't move at all. On other hardware the
> wheels go backwards and forwards where the screen refresh rate is just
> perfectly
On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
Hah I just wish gears would go away. If I get hardware where it runs at just
the right speed it looks like it doesn't move at all. On other hardware the
wheels go backwards and forwards where the screen refresh rate is just
perfectly a
Xavier Bestel wrote:
On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
Hah I just wish gears would go away. If I get hardware where it runs at
just the right speed it looks like it doesn't move at all. On other
hardware the wheels go backwards and forwards where the screen refresh
Gene Heskett wrote:
On Monday 05 March 2007, Nicolas Mailhot wrote:
This looks like -mm stuff if you want it in 2.6.22
This needs to get to 2.6.21, it really is that big an improvement.
As Con pointed out, for some workloads and desired behavour this is not
as good as the existing
Op Tuesday 06 March 2007, schreef Willy Tarreau:
In a way, I think they are right. Let me explain. Pluggable schedulers are
useful when you want to switch away from the default one. This is very
useful during development of a new scheduler, as well as when you're not
satisfied with the default
On Wednesday 07 March 2007 04:50, Bill Davidsen wrote:
Gene Heskett wrote:
On Monday 05 March 2007, Nicolas Mailhot wrote:
This looks like -mm stuff if you want it in 2.6.22
This needs to get to 2.6.21, it really is that big an improvement.
As Con pointed out, for some workloads and
Willy Tarreau wrote:
On Tue, Mar 06, 2007 at 11:18:44AM +1100, Con Kolivas wrote:
On Tuesday 06 March 2007 10:05, Bill Davidsen wrote:
jos poortvliet wrote:
Well, imho his current staircase scheduler already does a better job
compared to mainline, but it won't make it in (or at
Hi Bill,
On Tue, Mar 06, 2007 at 04:37:37PM -0500, Bill Davidsen wrote:
(...)
The point is that no one CPU scheduler will satisfy the policy needs of
all users, any more than one i/o scheduler does so. We have realtime
scheduling, preempt both voluntary and involuntary, why should we not
On Tue, 2007-03-06 at 05:41 +0100, Willy Tarreau wrote:
> On Tue, Mar 06, 2007 at 11:18:44AM +1100, Con Kolivas wrote:
> > On Tuesday 06 March 2007 10:05, Bill Davidsen wrote:
> > > jos poortvliet wrote:
> > > > Well, imho his current staircase scheduler already does a better job
> > > > compared
On Monday 05 March 2007 10:13, Willy Tarreau wrote:
> Con,
>
> I've now given it a try with HZ=250 on my dual-athlon. It works
> beautifully. I also quickly checked that playing mp3 doesn't skip during
> make -j4, and that gears runs fairly smoothly, since those are the
> references people often
On Tue, Mar 06, 2007 at 11:18:44AM +1100, Con Kolivas wrote:
> On Tuesday 06 March 2007 10:05, Bill Davidsen wrote:
> > jos poortvliet wrote:
> > > Well, imho his current staircase scheduler already does a better job
> > > compared to mainline, but it won't make it in (or at least, it's not
> > >
On Monday 05 March 2007, Linus Torvalds wrote:
>On Mon, 5 Mar 2007, Ed Tomlinson wrote:
>> The patch _does_ make a difference. For instance reading mail with
>> freenet working hard (threaded java application) and gentoo's emerge
>> triggering compiles to update the box is much smoother.
>>
>>
Hi,
I have had this in for about 24 hours. So far so good. I am running on IUP
amd64 with
'voluntary kernel Preemption' enabled (preemptible kernels seem to lock up solid
switching between 32 and 64 apps - no opps and nothing on the serial console...)
The patch _does_ make a difference. For
On Mon, 5 Mar 2007, Ed Tomlinson wrote:
>
> The patch _does_ make a difference. For instance reading mail with freenet
> working
> hard (threaded java application) and gentoo's emerge triggering compiles to
> update the
> box is much smoother.
>
> Think this scheduler needs serious
On Tuesday 06 March 2007 10:05, Bill Davidsen wrote:
> jos poortvliet wrote:
> > Well, imho his current staircase scheduler already does a better job
> > compared to mainline, but it won't make it in (or at least, it's not
> > likely). So we can hope this WILL make it into mainline, but I wouldn't
On Monday 05 March 2007, Andrew Morton wrote:
>On Mon, 05 Mar 2007 14:19:25 -0500
>
>Gene Heskett <[EMAIL PROTECTED]> wrote:
>> Andrew, please, get this one in ASAP,
>
>I'm presently nearly 1000 messages behind on my lkml reading. We'll get
>there.
>
>> but promise me an -mm won't trash
>> half
jos poortvliet wrote:
Op Sunday 04 March 2007, schreef Willy Tarreau:
Hi Con !
This was designed to be robust for any application since linux demands a
general purpose scheduler design, while preserving interactivity, instead
of optimising for one particular end use.
Well, I haven't tested it
On Mon, 05 Mar 2007 14:19:25 -0500
Gene Heskett <[EMAIL PROTECTED]> wrote:
> Andrew, please, get this one in ASAP,
I'm presently nearly 1000 messages behind on my lkml reading. We'll get
there.
> but promise me an -mm won't trash
> half my filesystems like one I tried 2-3 years ago did.
I
On Tuesday 06 March 2007 05:23, Al Boldi wrote:
> Con Kolivas wrote:
> > Gears just isn't an interactive task and just about anything but gears
> > would be a better test case since its behaviour varies wildly under
> > different combinations of graphics cards, memory bandwidth, cpu and so
> > on.
On Sunday 04 March 2007 18:00, Con Kolivas wrote:
> This message is to announce the first general public release of the
> "Rotating Staircase DeadLine" cpu scheduler.
> A full rollup of the patch for 2.6.20:
> http://ck.kolivas.org/patches/staircase-deadline/sched-rsdl-0.26.patch
This patch has
On Tuesday 06 March 2007 05:29, Simon Arlott wrote:
> On 04/03/07 22:27, Con Kolivas wrote:
> > On Monday 05 March 2007 09:19, Simon Arlott wrote:
> >> If I run glxgears, thunderbird/firefox become really slow to
> >> respond/display and cpu usage isn't even at 100%. I had thunderbird
> >> lagging
On Monday 05 March 2007, Lee Revell wrote:
>On 3/5/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>> On Monday 05 March 2007, Nicolas Mailhot wrote:
>> >This looks like -mm stuff if you want it in 2.6.22
>>
>> This needs to get to 2.6.21, it really is that big an improvement.
>
>You can probably
On Monday 05 March 2007, Paolo Ciarrocchi wrote:
>On 3/5/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>> On Monday 05 March 2007, Nicolas Mailhot wrote:
>> >This looks like -mm stuff if you want it in 2.6.22
>>
>> This needs to get to 2.6.21, it really is that big an improvement.
>
>On 3/5/07, Gene
On 04/03/07 22:27, Con Kolivas wrote:
On Monday 05 March 2007 09:19, Simon Arlott wrote:
If I run glxgears, thunderbird/firefox become really slow to
respond/display and cpu usage isn't even at 100%. I had thunderbird lagging
on keyboard character repeat earlier but can't reproduce that now
On 3/5/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
On Monday 05 March 2007, Nicolas Mailhot wrote:
>This looks like -mm stuff if you want it in 2.6.22
This needs to get to 2.6.21, it really is that big an improvement.
You can probably speed things up by regression testing against a wide
range
On 3/5/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
On Monday 05 March 2007, Nicolas Mailhot wrote:
>This looks like -mm stuff if you want it in 2.6.22
This needs to get to 2.6.21, it really is that big an improvement.
On 3/5/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
On Monday 05 March
On Monday 05 March 2007 22:59, Al Boldi wrote:
> Markus Törnqvist wrote:
> > On Mon, Mar 05, 2007 at 08:34:45AM +0300, Al Boldi wrote:
> > >Ok, gears is smooth when you run "make -j4", but with "nice make -j4",
> > > gears becomes bursty. This looks like a problem with nice-levels. In
> > >
Markus Törnqvist wrote:
> On Mon, Mar 05, 2007 at 08:34:45AM +0300, Al Boldi wrote:
> >Ok, gears is smooth when you run "make -j4", but with "nice make -j4",
> > gears becomes bursty. This looks like a problem with nice-levels. In
> > general, looking subjectively at top d.1, procs appear to
Le Lun 5 mars 2007 10:53, Gene Heskett a écrit :
> On Monday 05 March 2007, Nicolas Mailhot wrote:
>>This looks like -mm stuff if you want it in 2.6.22
>
> This needs to get to 2.6.21, it really is that big an improvement.
One can dream...
I suspect Linus will disagree, especially if it never
On Monday 05 March 2007, Nicolas Mailhot wrote:
>This looks like -mm stuff if you want it in 2.6.22
This needs to get to 2.6.21, it really is that big an improvement.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that
1 - 100 of 162 matches
Mail list logo
