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
David Lang wrote:
On Fri, 9 Mar 2007, Al Boldi wrote:
My preferred sphere of operation is the Manichean domain of faster vs.
slower, functionality vs. non-functionality, and the like. For me, such
design concerns are like the need for a kernel to format pagetables so
the x86 MMU decodes what
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
David Lang wrote:
On Fri, 9 Mar 2007, Al Boldi wrote:
My preferred sphere of operation is the Manichean domain of faster vs.
slower, functionality vs. non-functionality, and the like. For me, such
design concerns are like the need for a kernel to format pagetables so
the x86 MMU decodes what
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
William Lee Irwin III wrote:
>> Last I checked there were limits to runtime configurability centering
>> around only supporting a compiled-in set of scheduling drivers, unless
>> Peter's taken it the rest of the way without my noticing. It's unclear
>> what you have in mind in terms of dynamic
William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >> A useful exercise may also be enumerating
> >> your expectations and having those who actually work with the code
> >> describe how well those are actually met.
>
> On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote:
> > A
William Lee Irwin III wrote:
William Lee Irwin III wrote:
A useful exercise may also be enumerating
your expectations and having those who actually work with the code
describe how well those are actually met.
On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote:
A runtime
William Lee Irwin III wrote:
Last I checked there were limits to runtime configurability centering
around only supporting a compiled-in set of scheduling drivers, unless
Peter's taken it the rest of the way without my noticing. It's unclear
what you have in mind in terms of dynamic
William Lee Irwin III wrote:
This sort of concern is too subjective for me to have an opinion on it.
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
>>> How diplomatic.
William Lee Irwin III wrote:
>> Impoliteness doesn't accomplish anything I want to do.
On Sat, Mar 10, 2007 at
William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >> This sort of concern is too subjective for me to have an opinion on it.
>
> On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
> > How diplomatic.
>
> Impoliteness doesn't accomplish anything I want to do.
Fair enough. But
On Fri, Mar 09, 2007 at 05:18:31PM -0500, Ryan Hope wrote:
> from what I understood, there is a performance loss in plugsched
> schedulers because they have to share code
> even if pluggable schedulers is not a viable option, being able to
> choose which one was built into the kernel would be
On Fri, 9 Mar 2007, Al Boldi wrote:
My preferred sphere of operation is the Manichean domain of faster vs.
slower, functionality vs. non-functionality, and the like. For me, such
design concerns are like the need for a kernel to format pagetables so
the x86 MMU decodes what was intended, or
William Lee Irwin III wrote:
>> The short translation of my message for you is "Linus, please don't
>> LART me too hard."
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
> Right.
Given where the code originally came from, I've got bullets to dodge.
William Lee Irwin III wrote:
>>
from what I understood, there is a performance loss in plugsched
schedulers because they have to share code
even if pluggable schedulers is not a viable option, being able to
choose which one was built into the kernel would be easy (only takes a
few ifdefs), i too think competition would be
On Sunday 04 March 2007 01:00, Con Kolivas 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
William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >> I consider policy issues to be hopeless political quagmires and
> >> therefore stick to mechanism. So even though I may have started the
> >> code in question, I have little or nothing to say about that sort of
> >> use for it.
> >>
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
William Lee Irwin III wrote:
>> I consider policy issues to be hopeless political quagmires and
>> therefore stick to mechanism. So even though I may have started the
>> code in question, I have little or nothing to say about that sort of
>> use for it.
>> There's my longwinded excuse for having
William Lee Irwin III wrote:
> 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
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
William Lee Irwin III wrote:
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
William Lee Irwin III wrote:
I consider policy issues to be hopeless political quagmires and
therefore stick to mechanism. So even though I may have started the
code in question, I have little or nothing to say about that sort of
use for it.
There's my longwinded excuse for having originated
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,
William Lee Irwin III wrote:
William Lee Irwin III wrote:
I consider policy issues to be hopeless political quagmires and
therefore stick to mechanism. So even though I may have started the
code in question, I have little or nothing to say about that sort of
use for it.
There's my
On Sunday 04 March 2007 01:00, Con Kolivas 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
from what I understood, there is a performance loss in plugsched
schedulers because they have to share code
even if pluggable schedulers is not a viable option, being able to
choose which one was built into the kernel would be easy (only takes a
few ifdefs), i too think competition would be
William Lee Irwin III wrote:
The short translation of my message for you is Linus, please don't
LART me too hard.
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
Right.
Given where the code originally came from, I've got bullets to dodge.
William Lee Irwin III wrote:
This sort of
On Fri, 9 Mar 2007, Al Boldi wrote:
My preferred sphere of operation is the Manichean domain of faster vs.
slower, functionality vs. non-functionality, and the like. For me, such
design concerns are like the need for a kernel to format pagetables so
the x86 MMU decodes what was intended, or
On Fri, Mar 09, 2007 at 05:18:31PM -0500, Ryan Hope wrote:
from what I understood, there is a performance loss in plugsched
schedulers because they have to share code
even if pluggable schedulers is not a viable option, being able to
choose which one was built into the kernel would be easy
William Lee Irwin III wrote:
William Lee Irwin III wrote:
This sort of concern is too subjective for me to have an opinion on it.
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
How diplomatic.
Impoliteness doesn't accomplish anything I want to do.
Fair enough. But being
William Lee Irwin III wrote:
This sort of concern is too subjective for me to have an opinion on it.
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
How diplomatic.
William Lee Irwin III wrote:
Impoliteness doesn't accomplish anything I want to do.
On Sat, Mar 10, 2007 at
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
1 - 100 of 192 matches
Mail list logo
