On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rob Hussey <[EMAIL PROTECTED]> wrote:
>
> > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
>
> heh - am i the only one impressed by the consistency of the blue line in
> this graph? :-) [ and the green line look
Op Saturday 28 July 2007, schreef Linus Torvalds:
>
> Compare this to SD for a while. Ponder.
>
> Linus
Your point here seems to be: this is how it went, and it was right. Ok, got
that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder
how many did leave
Op Saturday 28 July 2007, schreef Linus Torvalds:
> On Sat, 28 Jul 2007, Michael Chang wrote:
> > I do recall there is one issue on which Con wouldn't budge -- anything
> > that involved boosting certain kinds of processes in the kernel.
>
> I did that myself, so that's a non-issue.
>
> No. The com
Op Tuesday 20 March 2007, schreef Linus Torvalds:
> On Mon, 19 Mar 2007, Xavier Bestel wrote:
> > > >> Stock scheduler wins easily, no contest.
> > > >
> > > > What happens when you renice X ?
> > >
> > > Dunno -- not necessary with the stock scheduler.
> >
> > Could you try something like renice -
Op Tuesday 20 March 2007, schreef Bill Davidsen:
> Kasper Sandberg wrote:
> > On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote:
> >> On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote:
> >>> I'd recon KDE regresses because of kioslaves waiting on a pipe
> >>> (communication with t
Op Sunday 18 March 2007, schreef Radoslaw Szkodzinski:
> On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > Hm. Sounds rather a lot like the...
> > X sucks, fix X and RSDL will rock your world. RSDL is perfect.
> > ...that I've been getting.
>
> Blah. Nothing's perfect. Especially not comp
Op Sunday 18 March 2007, schreef Mike Galbraith:
> On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
> > Now for something constructive... by any chance is Mike running KDE
> > instead of GNOME?
>
> Yes.
>
> -Mike
Well, then, it might indeed be the KIOslave/pipe stuff. I experience som
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
Op Saturday 17 March 2007, schreef Ingo Molnar:
> * jos poortvliet <[EMAIL PROTECTED]> wrote:
> > Op Saturday 17 March 2007, schreef Ingo Molnar:
> > > so it is not at all clear to me that RSDL is indeed an improvement,
> > > if it does not have comparable auto-ni
Op Saturday 17 March 2007, schreef Con Kolivas:
> On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
> > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > Despite the claims to the contrary, RSDL does not have _less_
> > > heuristics, it does not have _any_. It's purely entitlement based.
> >
> > RSD
Op Saturday 17 March 2007, schreef Ingo Molnar:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Despite the claims to the contrary, RSDL does not have _less_
> > heuristics, it does not have _any_. It's purely entitlement based.
>
> RSDL still has heuristics very much, but this time it's hardcoded i
Op Saturday 17 March 2007, schreef Ingo Molnar:
> so it is not at all clear to me that RSDL is indeed an improvement, if
> it does not have comparable auto-nice properties.
Wasn't the point of RSDL to get rid of the auto-nice, because it caused
starvation, unpredictable behaviour and other proble
Op Monday 12 March 2007, schreef Con Kolivas:
> > > If we fix 95% of the desktop and worsen 5% is that bad given how much
> > > else we've gained in the process?
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have
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
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
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
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
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
Op Saturday 10 February 2007, schreef Randy Dunlap:
> On Fri, 09 Feb 2007 18:35:51 -0500 Chuck Ebbert wrote:
> > Andrew Morton wrote:
> > > I have an email sitting in my drafts folder stating that I'll no longer
> > > accept any features unless they've been publically reviewed in detail
> > > and r
Op Friday 09 February 2007, schreef Con Kolivas:
> On Saturday 10 February 2007 00:13, jos poortvliet wrote:
> > Nobody has said anything about costs, indeed. Now afaik, swap prefetch is
> > designed to have no/as little as possible costs, so that makes sense.
> > Does it h
> > > Hold.
> > Why hold?
>
> > It's been shown this patchset really helps desktop users.
>
> Has it? I don't think I've ever observed any benefits from it and I don't
> think anyone has ever got down and worked out what its drawbacks might be,
> and seen if they can be demonstrated in practice.
Op Sat Dec 9 2006, schreef Con Kolivas:
(cut)
> Changes (first significant changes since :
> Added:
> +sched-fix_iso_starvation.patch
> A bug first introduced into 2.6.18-ck1/cks1 meant that SCHED_ISO tasks were
> not being throttled when above their cpu limit. This presents a security
> risk to a
22 matches
Mail list logo
