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 waiti
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
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 ano
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 p
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 ex
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 the
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
> > > > pr
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
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 f
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
> >
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 i
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
> > runq
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 b
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
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:
http://marc.theaimsgroup.com/?l=linux-kernel&m=1173310030293
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 exte
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 runti
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 0
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 be
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 e
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 fo
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
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 g
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 whic
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.
> >> T
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 *detes
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 or
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:
> 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 schedulers.
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 n
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 l
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,
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: sen
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 "unsubscri
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
> > de
* 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 sa
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 worklo
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 defa
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 scheduler.
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
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 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 t
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 us
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
> > > l
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.
>>
>> Th
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 i
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 lookin
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 my
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 can
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 speed
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 even
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 2007,
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
> > > gener
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 show
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 was
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 order."
This looks like -mm stuff if you want it in 2.6.22
--
Nicolas Mailhot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.
On Sunday 04 March 2007, Zwane Mwaikambo wrote:
>On Sun, 4 Mar 2007, Gene Heskett wrote:
>> >There will be times when the mainline scheduler feels more
>> > interactive than this scheduler, and that is because it has
>> > significant unfairness granted towards interactive tasks. This
>> > degree of
On Sun, 4 Mar 2007, Gene Heskett wrote:
> >There will be times when the mainline scheduler feels more interactive
> > than this scheduler, and that is because it has significant unfairness
> > granted towards interactive tasks. This degree of unfairness in an
> > effort to maintain interactivity h
On Sunday 04 March 2007, Willy Tarreau wrote:
>On Mon, Mar 05, 2007 at 08:49:29AM +1100, Con Kolivas wrote:
>(...)
>
>> > That's just what it did, but when you "nice make -j4", things
>> > (gears) start to stutter. Is that due to the staircase?
>>
>> gears isn't an interactive task. Apart from usi
On Monday 05 March 2007 10:13, Willy Tarreau wrote:
> I've now given it a try with HZ=250 on my dual-athlon.
Great, thanks. The HZ should make very little difference, except for slightly
lower latencies as you increase the HZ.
> It works
> beautifully. I also quickly checked that playing mp3 do
Op Monday 05 March 2007, schreef Willy Tarreau:
> On Mon, Mar 05, 2007 at 08:49:29AM +1100, Con Kolivas wrote:
> (...)
>
> > > That's just what it did, but when you "nice make -j4", things (gears)
> > > start to stutter. Is that due to the staircase?
> >
> > gears isn't an interactive task. Apart
On Mon, Mar 05, 2007 at 08:49:29AM +1100, Con Kolivas wrote:
(...)
> > That's just what it did, but when you "nice make -j4", things (gears) start
> > to stutter. Is that due to the staircase?
>
> gears isn't an interactive task. Apart from using it as a background load to
> check for starvation
On Monday 05 March 2007 09:19, Simon Arlott wrote:
> On 04/03/07 21:49, Con Kolivas wrote:
> > On Monday 05 March 2007 07:35, Al Boldi wrote:
> >> Con Kolivas wrote:
> >>> This means that if you heavily load up your machine without the use of
> >>> 'nice' then your interactive tasks _will_ slow dow
On Monday 05 March 2007 07:35, Al Boldi wrote:
> Con Kolivas wrote:
> > > >> >> >This message is to announce the first general public release of
> > > >> >> > the "Rotating Staircase DeadLine" cpu scheduler.
>
> Thanks a lot!
You're welcome.
>
> > Just to make it clear. The purpose of this schedul
Con Kolivas wrote:
> > >> >> >This message is to announce the first general public release of
> > >> >> > the "Rotating Staircase DeadLine" cpu scheduler.
Thanks a lot!
> Just to make it clear. The purpose of this scheduler is at all costs to
> maintain absolute fairness no matter what type of lo
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 yet, but
Hi Con !
On Mon, Mar 05, 2007 at 12:49:49AM +1100, Con Kolivas wrote:
> On Monday 05 March 2007 00:25, Gene Heskett wrote:
> > On Sunday 04 March 2007, Con Kolivas wrote:
> > >On Sunday 04 March 2007 23:24, Gene Heskett wrote:
> > >> On Sunday 04 March 2007, Con Kolivas wrote:
> > >> >On Sunday 04
On Sunday 04 March 2007, Con Kolivas wrote:
>On Monday 05 March 2007 00:25, Gene Heskett wrote:
>> On Sunday 04 March 2007, Con Kolivas wrote:
>> >On Sunday 04 March 2007 23:24, Gene Heskett wrote:
>> >> On Sunday 04 March 2007, Con Kolivas wrote:
>> >> >On Sunday 04 March 2007 22:08, Gene Heskett
On Sunday 04 March 2007 18:45, Con Kolivas wrote:
> 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.
> >
> > Based on previous work from the staircase cpu scheduler I set out to
On Monday 05 March 2007 00:25, Gene Heskett wrote:
> On Sunday 04 March 2007, Con Kolivas wrote:
> >On Sunday 04 March 2007 23:24, Gene Heskett wrote:
> >> On Sunday 04 March 2007, Con Kolivas wrote:
> >> >On Sunday 04 March 2007 22:08, Gene Heskett wrote:
> >> >> On Sunday 04 March 2007, Con Koliv
On Sunday 04 March 2007, Con Kolivas wrote:
>On Sunday 04 March 2007 23:24, Gene Heskett wrote:
>> On Sunday 04 March 2007, Con Kolivas wrote:
>> >On Sunday 04 March 2007 22:08, Gene Heskett wrote:
>> >> On Sunday 04 March 2007, Con Kolivas wrote:
>> >> >This message is to announce the first genera
On Sunday 04 March 2007 23:24, Gene Heskett wrote:
> On Sunday 04 March 2007, Con Kolivas wrote:
> >On Sunday 04 March 2007 22:08, Gene Heskett wrote:
> >> On Sunday 04 March 2007, Con Kolivas wrote:
> >> >This message is to announce the first general public release of the
> >> > "Rotating Staircas
On Sunday 04 March 2007, Con Kolivas wrote:
>On Sunday 04 March 2007 22:08, Gene Heskett wrote:
>> On Sunday 04 March 2007, Con Kolivas wrote:
>> >This message is to announce the first general public release of the
>> > "Rotating Staircase DeadLine" cpu scheduler.
>>
>> I assume to test this, we se
On Sunday 04 March 2007 22:08, Gene Heskett wrote:
> On Sunday 04 March 2007, Con Kolivas wrote:
> >This message is to announce the first general public release of the
> > "Rotating Staircase DeadLine" cpu scheduler.
>
> I assume to test this, we select the deadline scheduler?
No, only the "deadli
On Sunday 04 March 2007, Con Kolivas wrote:
>This message is to announce the first general public release of the
> "Rotating Staircase DeadLine" cpu scheduler.
I assume to test this, we select the deadline scheduler?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap,
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.
>
> Based on previous work from the staircase cpu scheduler I set out to
> design, from scratch, a new scheduling policy design whic
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 every
requirement for SCHED_NORMAL (otherwi
96 matches
Mail list logo
