David Schwartz wrote:
Bill Davidsen wrote:
I agree for giving a process more than a fair share, but I don't think
"latency" is the best term for what you describe later. If you think of
latency as the time between a process unblocking and the time when it
gets CPU, that is a more traditional i
Bill Davidsen wrote:
> I agree for giving a process more than a fair share, but I don't think
> "latency" is the best term for what you describe later. If you think of
> latency as the time between a process unblocking and the time when it
> gets CPU, that is a more traditional interpretation. I'
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Willy Tarreau wrote:
Linus, you're unfair with Con. He initially was on this position, and lately
worked with Mike by proposing changes to try to improve his X responsiveness.
I was not actually so much speaking about Con, as about a lot of the
tone
David Schwartz wrote:
there were multiple attempts with renicing X under the vanilla
scheduler, and they were utter failures most of the time. _More_ people
complained about interactivity issues _after_ X has been reniced to -5
(or -10) than people complained about "nice 0" interactivity issues t
On Fri, 2007-03-23 at 16:59 +1100, Con Kolivas wrote:
>
> The deadline mechanism is easy to hit and works. Try printk'ing it.
I tried rc4-rsdl.33, and in a log that's 782kb, there is only one
instance of an overrun, which I created. On my box, it's dead code.
-Mike
-
To unsubscribe f
On Fri, 2007-03-23 at 16:59 +1100, Con Kolivas wrote:
> The deadline mechanism is easy to hit and works. Try printk'ing it.
Hm. I did (.30), and it didn't in an hours time doing this and that.
After I did the take your quota with you, it did kick in. Lots.
-Mike
-
To unsubscribe from
On Friday 23 March 2007 15:39, Mike Galbraith wrote:
> On Fri, 2007-03-23 at 09:50 +1100, Con Kolivas wrote:
> > Now to figure out some meaningful cheap way of improving this accounting.
>
> The accounting is easy iff tick resolution is good enough, the deadline
> mechanism is harder. I did the "q
On Fri, 2007-03-23 at 09:50 +1100, Con Kolivas wrote:
> Now to figure out some meaningful cheap way of improving this accounting.
The accounting is easy iff tick resolution is good enough, the deadline
mechanism is harder. I did the "quota follows task" thing, but nothing
good happens. That jus
Thanks for taking the time to actually look at the code. All audits are most
welcome!.
On Thursday 22 March 2007 18:07, Mike Galbraith wrote:
> This is a rather long message, and isn't directed at anyone in
> particular, it's for others who may be digging into their own problems
> with RSDL, and
All code reviews are most welcome indeed!
On Thursday 22 March 2007 20:18, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > Actually, the numbers are an interesting curiosity point, but not as
> > interesting as the fact that the deadline mechanism isn't kicking in.
>
> it's no
On Thu, 2007-03-22 at 10:34 +0100, Mike Galbraith wrote:
> Erk!
bzzt. singletasking brain :)
-
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
On Thu, 2007-03-22 at 10:18 +0100, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > Actually, the numbers are an interesting curiosity point, but not as
> > interesting as the fact that the deadline mechanism isn't kicking in.
>
> it's not just the scheduling accounting bei
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> Actually, the numbers are an interesting curiosity point, but not as
> interesting as the fact that the deadline mechanism isn't kicking in.
it's not just the scheduling accounting being off, RSDL also seems to be
accessing stale data here:
> >Fro
On Thu, 2007-03-22 at 05:49 +0100, Willy Tarreau wrote:
> Mike, if you need my old scheddos, I can resend it to you as well as to
> any people working on the scheduler and asking for it. Although trivial,
> I'm a bit reluctant to publish it to the whole world because I suspect
> that distros based
This is a rather long message, and isn't directed at anyone in
particular, it's for others who may be digging into their own problems
with RSDL, and for others (if any other than Con exist) who understand
RSDL well enough to tell me if I'm missing something. Anyone who's not
interested in RSDL's g
On Wed, Mar 21, 2007 at 06:07:33PM +0100, Mike Galbraith wrote:
> On Wed, 2007-03-21 at 16:11 +0100, Paolo Ornati wrote:
> > On Wed, 21 Mar 2007 15:57:44 +0100
> > Mike Galbraith <[EMAIL PROTECTED]> wrote:
> >
> > > I was more than a bit surprised that mainline did this well, considering
> > > tha
Al Boldi wrote:
> Artur Skawina wrote:
>> Al Boldi wrote:
>>> - p->quota = rr_quota(p);
>>> + /*
>>> +* boost factor hardcoded to 5; adjust to your liking
>>> +* higher means more likely to DoS
>>> +*/
>>> + p->quota = rr_quota(p) + (((now - p->timestamp) >> 20) * 5);
>> mouse cu
On Wed, 2007-03-21 at 16:11 +0100, Paolo Ornati wrote:
> On Wed, 21 Mar 2007 15:57:44 +0100
> Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > I was more than a bit surprised that mainline did this well, considering
> > that the proggy was one someone posted long time ago to demonstrate
> > starvat
On Wed, 2007-03-21 at 17:02 +0100, Peter Zijlstra wrote:
> On Wed, 2007-03-21 at 15:57 +0100, Mike Galbraith wrote:
>
> > 'f' is a progglet which sleeps a bit and burns a bit, duration depending
> > on argument given. 'sh' is a shell 100% hog. In this scenario, the
> > argument was set such that
On Wed, 2007-03-21 at 15:57 +0100, Mike Galbraith wrote:
> 'f' is a progglet which sleeps a bit and burns a bit, duration depending
> on argument given. 'sh' is a shell 100% hog. In this scenario, the
> argument was set such that 'f' used right at 50% cpu. All are started
> at the same time, and
On Tue, 2007-03-20 at 09:03 +0100, Mike Galbraith wrote:
> Moving right along to the bugs part, I hope others are looking as well,
> and not only talking.
>
> One area that looks pretty fishy to me is cross-cpu wakeups and task
> migration. p->rotation appears to lose all meaning when you cross
> there were multiple attempts with renicing X under the vanilla
> scheduler, and they were utter failures most of the time. _More_ people
> complained about interactivity issues _after_ X has been reniced to -5
> (or -10) than people complained about "nice 0" interactivity issues to
> begin with.
On Mon, 2007-03-19 at 16:47 -0400, Bill Davidsen wrote:
> 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
> >>> (communic
On Tue, 2007-03-20 at 08:16 -0700, Ray Lee wrote:
> On 3/20/07, Mark Lord <[EMAIL PROTECTED]> wrote:
> > I've droppped it from my machine -- interactive response is much
> > more important for my primary machine right now.
>
> Help out with a data point? Are you running KDE as well? If you are,
>
Another data point: I'm getting stalls in mplayer. I'm assuming the stalls
occur when procmail runs messages through spamprobe, as the system is
otherwise idle. The stalls continue to occur (and I'm not sure that they
aren't worse) when X and/or mplayer are reniced to negative nice levels.
This is
* Xavier Bestel <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote:
> > I don't agree with starting to renice X to get something usable
>
> [...] Why not compensate for X design by prioritizing it a bit ?
there were multiple attempts with renicing X under the van
Artur Skawina wrote:
> Al Boldi wrote:
> > --- sched.bak.c 2007-03-16 23:07:23.0 +0300
> > +++ sched.c 2007-03-19 23:49:40.0 +0300
> > @@ -938,7 +938,11 @@ static void activate_task(struct task_st
> > (now - p->timestamp) >> 20);
> > }
> >
>
Al Boldi wrote:
> --- sched.bak.c 2007-03-16 23:07:23.0 +0300
> +++ sched.c 2007-03-19 23:49:40.0 +0300
> @@ -938,7 +938,11 @@ static void activate_task(struct task_st
>(now - p->timestamp) >> 20);
> }
>
> - p->quota = rr_quota
Linus Torvalds wrote:
> I was very happy to see the "try this patch" email from Al Boldi - not
> because I think that patch per se was necessarily the right fix (I have no
> idea),
Well, it wasn't really meant as a fix, but rather to point out that
interactivity boosting is possible with RSDL.
On Tue, 20 Mar 2007, Willy Tarreau wrote:
>
> Linus, you're unfair with Con. He initially was on this position, and lately
> worked with Mike by proposing changes to try to improve his X responsiveness.
I was not actually so much speaking about Con, as about a lot of the
tone in general here.
Ray Lee wrote:
On 3/20/07, Mark Lord <[EMAIL PROTECTED]> wrote:
I've droppped it from my machine -- interactive response is much
more important for my primary machine right now.
Help out with a data point? Are you running KDE as well?
Yes, KDE.
-
To unsubscribe from this list: send the line
On 3/20/07, Mark Lord <[EMAIL PROTECTED]> wrote:
I've droppped it from my machine -- interactive response is much
more important for my primary machine right now.
Help out with a data point? Are you running KDE as well? If you are,
then it looks like the common denominator that RSDL is handling
Linus Torvalds wrote:
Quite frankly, I was *planning* on merging RSDL very early after 2.6.21,
but there is one thing that has turned me completely off the whole thing:
- the people involved seem to be totally unwilling to even admit there
might be a problem.
Not to mention that it see
Xavier Bestel wrote:
> On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote:
>> I don't agree with starting to renice X to get something usable
>
> X looks very special to me: it's a big userspace driver, the primary
> task handling user interaction on the desktop, and on some OS the part
> resp
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
On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote:
> I don't agree with starting to renice X to get something usable
X looks very special to me: it's a big userspace driver, the primary
task handling user interaction on the desktop, and on some OS the part
responsible for moving the mouse poi
On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote:
> Also, while I don't agree with starting to renice X to get something usable,
> it seems real that there's something funny on Mike's system which makes it
> behave particularly strangely when combined with RSDL, because other people
> in com
On Mon, Mar 19, 2007 at 08:11:55PM -0700, Linus Torvalds wrote:
> Quite frankly, I was *planning* on merging RSDL very early after 2.6.21,
> but there is one thing that has turned me completely off the whole thing:
>
> - the people involved seem to be totally unwilling to even admit there
>
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 -10 $(pidof Xorg) ?
Could you try something as simple and acc
Mark Lord wrote:
> Al Boldi wrote:
> >..
> > Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than
> > mainline. Try this easy test:
> >
> > startx with the vesa driver
> > run reflect from the mesa5.0-demos
> > load 5 cpu-hogs
> > start moving the mouse
> >
> > On my desktop, main
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 the app they're doing IO for) and then expiring.
That's why splittin
On Mon, 2007-03-19 at 12:36 -0400, Mark Lord wrote:
> Xavier Bestel wrote:
> > On Mon, 2007-03-19 at 12:07 -0400, Mark Lord wrote:
> >> Dell notebook, single P-M-2GHz, ATI X300, open source X.org:
> >> (1) build a kernel in one window with "make -j$((NUMBER_OF_CPUS +
> 1))".
> >> (2) try to read em
Xavier Bestel wrote:
On Mon, 2007-03-19 at 12:07 -0400, Mark Lord wrote:
Dell notebook, single P-M-2GHz, ATI X300, open source X.org:
(1) build a kernel in one window with "make -j$((NUMBER_OF_CPUS + 1))".
(2) try to read email and/or surf in Firefox/Thunderbird.
Stock scheduler wins easily, no
On Mon, 2007-03-19 at 12:07 -0400, Mark Lord wrote:
> Dell notebook, single P-M-2GHz, ATI X300, open source X.org:
> (1) build a kernel in one window with "make -j$((NUMBER_OF_CPUS + 1))".
> (2) try to read email and/or surf in Firefox/Thunderbird.
>
> Stock scheduler wins easily, no contest.
Wha
Al Boldi wrote:
..
Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than
mainline. Try this easy test:
startx with the vesa driver
run reflect from the mesa5.0-demos
load 5 cpu-hogs
start moving the mouse
On my desktop, mainline completely breaks down, and no nicing may rescu
Mike Galbraith wrote:
On Sat, 2007-03-17 at 20:48 +1100, Con Kolivas wrote:
The most frustrating part of a discussion of this nature on lkml is that
earlier information in a thread seems to be long forgotten after a few days
and all that is left is the one reporter having a problem.
One? I'
Just so you know the context, I'm coming at this from the point of view
of an embedded call server designer.
Mark Hahn wrote:
why do you think fairness is good, especially always good?
Fairness is good because it promotes predictability. See the
"deterministic" section below.
even star
On Mon, Mar 19, 2007 at 07:21:47AM +0100, Mike Galbraith wrote:
> On Sun, 2007-03-18 at 19:27 -0700, David Schwartz wrote:
>
> > > Wrong. I call a good job giving a _preference_ to the desktop. I call
> > > rigid fairness impractical for the desktop, and a denial of reality.
> >
> > Assuming yo
On Sun, 2007-03-18 at 19:27 -0700, David Schwartz wrote:
> > Wrong. I call a good job giving a _preference_ to the desktop. I call
> > rigid fairness impractical for the desktop, and a denial of reality.
>
> Assuming you *want* that. It's possible that the desktop may not be
> particularly impo
> P.S. "utter failure" was too harsh. What sticks in my craw is that the
> world has to adjust to fit this new scheduler.
>
> -Mike
Even when it's totally clear that this scheduler is doing what you asked it
do while the old one wasn't? It still bothers you that now you have to ask
for wh
On Sun, 18 Mar 2007, Lee Revell wrote:
On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
P.S. "utter failure" was too harsh. What sticks in my craw is that the
world has to adjust to fit this new scheduler.
I have never seen X run nearly as smooth as our favorite proprietary
OS on simil
On Sun, 2007-03-18 at 15:37 -0400, Lee Revell wrote:
> On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > P.S. "utter failure" was too harsh. What sticks in my craw is that the
> > world has to adjust to fit this new scheduler.
>
> I have never seen X run nearly as smooth as our favorite
On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
P.S. "utter failure" was too harsh. What sticks in my craw is that the
world has to adjust to fit this new scheduler.
I have never seen X run nearly as smooth as our favorite proprietary
OS on similar spec hardware with ANY scheduler.
Lee
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
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 computer programs.
Still, it's not a smart decision on KDE's part.
It wi
On 3/18/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote:
not really, only X sucks. KDE works atleast as good with rsdl as
vanilla. i dont know how originally said kde works worse, wasnt it just
someone that thought?
Couldn't agree more, been using RSDL+KDE for a week now, and as far as
I'm concer
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 the app they're doing IO for) and then expiring.
> > That's why splitting IO from a
On Sun, 2007-03-18 at 13:50 +0530, jimmy bahuleyan wrote:
> maybe if it is possible to classify program behaviors that cause RSDL to
> do bad (relatively) or the mainline scheduler to jitter, we could try
> modifying the existing heuristics to get a better default scheduler.
>
> of course, it wou
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 the app they're doing IO for) and then expiring.
>> That's why splitting IO from an app isn't exactly smart. It should a
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 the app they're doing IO for) and then expiring.
> > That's why splitting IO from a
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 the app they're doing IO for) and then expiring.
> That's why splitting IO from an app isn't exactly smart. It should at
> least be ran in an anothe
On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
On Sun, 2007-03-18 at 07:47 +0100, Kasper Sandberg wrote:
> > So neither does a good job with this load.
> that sorely depends on what you mean by good job.
>
> It seems like what you call a good job is preserving the speed of the
> gui(X + a
On Sun, 2007-03-18 at 07:47 +0100, Kasper Sandberg wrote:
> > So neither does a good job with this load.
> that sorely depends on what you mean by good job.
>
> It seems like what you call a good job is preserving the speed of the
> gui(X + apps which uses it) at _ALL_ costs to other stuff.
Wron
On Sun, 2007-03-18 at 07:17 +0100, Mike Galbraith wrote:
> On Sat, 2007-03-17 at 23:55 +0300, Al Boldi wrote:
>
> > Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than
> > mainline. Try this easy test:
> >
> > startx with the vesa driver
> > run reflect from the mesa5.0-demos
On Sat, 2007-03-17 at 23:55 +0300, Al Boldi wrote:
> Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than
> mainline. Try this easy test:
>
> startx with the vesa driver
> run reflect from the mesa5.0-demos
> load 5 cpu-hogs
> start moving the mouse
>
> On my desktop, mainline
Mike Galbraith wrote:
> On Sat, 2007-03-17 at 20:48 +1100, Con Kolivas wrote:
> > The most frustrating part of a discussion of this nature on lkml is that
> > earlier information in a thread seems to be long forgotten after a few
> > days and all that is left is the one reporter having a problem.
>
On Sat, 2007-03-17 at 19:23 +0100, Kacper Wysocki wrote:
> And for Mark and others who are as confused as I was, this is the
> thread that Mike meant to reference:
> http://thread.gmane.org/gmane.linux.kernel/503455/focus=6614
Nope, with all the back and forth (and noise), I lost track of which
t
On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
On Sat, 2007-03-17 at 13:03 -0400, Gene Heskett wrote:
> On Saturday 17 March 2007, Mike Galbraith wrote:
> [...]
> >Xorg is using 50% cpu because I'm asking it to.
>
> What advantage is that giving you?
It's a test scenario. Read the thread
On Sat, 2007-03-17 at 13:03 -0400, Gene Heskett wrote:
> On Saturday 17 March 2007, Mike Galbraith wrote:
> [...]
> >Xorg is using 50% cpu because I'm asking it to.
>
> What advantage is that giving you?
It's a test scenario. Read the thread please, I really don't want to
repeat myself endlessly
Mark Hahn wrote:
So in an attempt to summarise the situation, what are the advantages of RSDL
over mainline.
Fairness
why do you think fairness is good, especially always good?
Starvation free
even starvation is sometimes a good thing - there's a place for processes
that only
On Saturday 17 March 2007, Mike Galbraith wrote:
[...]
>Xorg is using 50% cpu because I'm asking it to.
What advantage is that giving you?
> -Mike
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdersh
Con Kolivas wrote:
> DEF_TIMESLICE is a value used for smp balancing and has no effect on quota
> so I doubt you mean that value. The quota you're describing of not
> resetting is something like the sleep average idea of current systems
> where you accumulate bonus points by sleeping when you would
So in an attempt to summarise the situation, what are the advantages of RSDL
over mainline.
Fairness
why do you think fairness is good, especially always good?
Starvation free
even starvation is sometimes a good thing - there's a place for processes
that only use the CPU if it is otherwise
* Rik van Riel <[EMAIL PROTECTED]> wrote:
> The increased AIM7 throughput (and the other benchmark results) looked
> very promising to me.
>
> I wonder what we're doing wrong in the normal scheduler...
there's a relatively easy way to figure out whether it's related to the
interactivity code:
On Sat, 2007-03-17 at 07:54 -0700, Mark Glines wrote:
> On Sat, 17 Mar 2007 15:33:41 +0100
> Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P
> > > > COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1
> > > > 7:08.70 0 Xorg
> > >
On Sat, 17 Mar 2007 15:33:41 +0100
Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P
> > > COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1
> > > 7:08.70 0 Xorg
> >
>
> This is a snippet from a hacked up by me version of RSDL.30
On Sat, 2007-03-17 at 10:32 -0400, Rik van Riel wrote:
> Mike Galbraith wrote:
>
> > If this is your final answer to the problem space, I am done testing,
> > and as far as _I_ am concerned, your scheduler is an utter failure.
>
> The increased AIM7 throughput (and the other benchmark results)
>
On Sat, 17 Mar 2007 09:46:27 +0100
Mike Galbraith <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-03-16 at 23:44 -0800, David Lang wrote:
>
> > why isn't niceing X to -10 an acceptable option?
>
> Xorg's priority is only part of the problem. Every client that needs
> a substantial quantity of cpu whi
On Sat, 2007-03-17 at 07:09 -0700, Mark Glines wrote:
> I don't suppose you can be a bit more specific, and define how much CPU
> constitutes a "substantial quantity"? It looks to me like X already got
> about half of a CPU.
>
> > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COM
Mike Galbraith wrote:
If this is your final answer to the problem space, I am done testing,
and as far as _I_ am concerned, your scheduler is an utter failure.
The increased AIM7 throughput (and the other benchmark results)
looked very promising to me.
I wonder what we're doing wrong in the n
On Saturday 17 March 2007 07:07, jos poortvliet 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-nice properties.
>
> Wasn't the point of RSDL to get rid of the auto-nice, becaus
On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
On Sat, 2007-03-17 at 20:48 +1100, Con Kolivas wrote:
> The most frustrating part of a discussion of this nature on lkml is that
> earlier information in a thread seems to be long forgotten after a few days
> and all that is left is the one r
On Saturday 17 March 2007 02:08, Mike Galbraith wrote:
> P.S. "utter failure" was too harsh. What sticks in my craw is that the
> world has to adjust to fit this new scheduler.
If a new scheduler has a better 'normal' performance adjusting to its quirks
is fine. Your testing is important. We n
On Saturday 17 March 2007 00:57, Con Kolivas wrote:
> On Saturday 17 March 2007 15:40, Al Boldi wrote:
> > Con Kolivas wrote:
> > > On Saturday 17 March 2007 08:55, Al Boldi wrote:
> > > > With X nice'd at -10, and 11 hogs loading the cpu, interactivity looks
> > > > good until the default timeslic
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-nice properties.
> >
> > Wasn't the p
On Sat, 2007-03-17 at 08:05 -0400, Gene Heskett wrote:
> >
> >top - 11:35:50 up 57 min, 12 users, load average: 5.20, 4.30, 2.57
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND
> > 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg
> > 7991 root 2
* 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-nice properties.
>
> Wasn't the point of RSDL to get rid of the auto-nice, because it
>
On Saturday 17 March 2007, Mike Galbraith wrote:
>Rocks and clubs at work (down boy , down i say!;).
>
>This is .30 with some targeted unfairness. I seem to be making progress
Try -0.31, its better yet.
>toward beating it to a bloody but cooperative pulp. It might be
>possible to have my cake an
On Saturday 17 March 2007, Mike Galbraith wrote:
>On Fri, 2007-03-16 at 23:26 -0700, Nicholas Miell wrote:
>> RSDL appears to be completely deterministic, which is a very strong
>> virtue.
>
>Yes. That's why RSDL aroused my curiosity big time.
>
>> The X people have plans for how to go about fixin
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
Rocks and clubs at work (down boy , down i say!;).
This is .30 with some targeted unfairness. I seem to be making progress
toward beating it to a bloody but cooperative pulp. It might be
possible to have my cake and eat it too. Likely too ugly to live
though.
top - 11:35:50 up 57 min, 12 users,
On Sat, 2007-03-17 at 20:48 +1100, Con Kolivas wrote:
> The most frustrating part of a discussion of this nature on lkml is that
> earlier information in a thread seems to be long forgotten after a few days
> and all that is left is the one reporter having a problem.
One? I'm not the only pers
On Saturday 17 March 2007 19:41, Serge Belyshev wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> > * Nicholas Miell <[EMAIL PROTECTED]> wrote:
> >> The X people have plans for how to go about fixing this, [...]
> >
> > [...] Or will X regress forever once we switch to RSDL?)
> > We cannot regress
On Fri, 2007-03-16 at 23:44 -0800, David Lang wrote:
> why isn't niceing X to -10 an acceptable option?
Xorg's priority is only part of the problem. Every client that needs a
substantial quantity of cpu while a hog is running will also need to be
negative nice, no?
> if you overload the box eno
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
>> The X people have plans for how to go about fixing this, [...]
>
> [...] Or will X regress forever once we switch to RSDL?)
> We cannot regress the scheduling of a workload as important as "X mixed
> with
(sorry for the duplicate Ingo, this time I managed to Repy to All)
On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > The X people have plans for how to go about fixing this, [...]
>
> then we'll first have wait for those X changes to at lea
On Sat, 17 Mar 2007, Ingo Molnar wrote:
* Nicholas Miell <[EMAIL PROTECTED]> wrote:
The X people have plans for how to go about fixing this, [...]
then we'll first have wait for those X changes to at least be done in a
minimal manner so that they can be tested for real with RSDL. (is it
_rea
* Nicholas Miell <[EMAIL PROTECTED]> wrote:
> > I'm saying that the current scheduler adjusts for interactive loads,
> > this new one doesn't. I'm seeing interactivity regressions, and
> > they are not fixed with nice unless nice is used to maximum effect.
> > I'm saying yes, I can lower my
* Nicholas Miell <[EMAIL PROTECTED]> wrote:
> The X people have plans for how to go about fixing this, [...]
then we'll first have wait for those X changes to at least be done in a
minimal manner so that they can be tested for real with RSDL. (is it
_really_ due to that? Or will X regress fore
1 - 100 of 120 matches
Mail list logo
