Hi!
> >> > Killing the known corner case starvation scenarios
> >is wonderful, but
> >> > let's not just pretend that interactive tasks don't
> >have any special
> >> > requirements.
> >>
> >> Now you're really making a stretch of things. Where
> >on earth did I say that
> >> interactive tasks
On Wed, 2007-03-14 at 04:25 +0100, Gabriel C wrote:
> [EMAIL PROTECTED] wrote:
> > On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> >
> >> with latest xorg, xlib will be using xcb internally,
> >>
> >
> > Out of curiosity, when is this "latest" Xorg going to escape to distros,
> >
[EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
Already is .. Xorg 7.2+ libx11 build with xcb enabled..
and is it far e
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
and is it far enough along that beta testers can gather usable numbers?
pgpt7KqlXv9Rp.pgp
Description: PGP sign
> a previous discussion that said 4 was the default...I don't see
> why. nice uses +10 by default on all linux distro...So I suspect
> that if Mike just used "nice lame" instead of "nice +5 lame", he
> would have got what he wanted.
tcsh, and probably csh, has a builtin 'nice' with default +4. So
On Tue, Mar 13, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote:
> David Schwartz wrote:
> Hm, well. The general preference has been for the kernel to do a
> good-enough job on getting the common cases right without tuning, and
> then only add knobs for the really tricky cases it can't do well
On Tue, Mar 13, 2007 at 12:58:01PM -0700, David Schwartz wrote:
> > But saying that the user needs to explicitly hold the schedulers hand
> > and nice everything to tell it how to schedule seems to be an abdication
> > of duty, an admission of failure. We can't expect users to finesse all
> > thei
David Schwartz wrote:
>> There's a distinction between giving it more cpu and giving it higher
>> priority: the important part about having high priority is getting low
>> latency access to the cpu when its needed.
>>
>
> I agree. Tasks that voluntarily relinquish their timeslices should get l
> There's a distinction between giving it more cpu and giving it higher
> priority: the important part about having high priority is getting low
> latency access to the cpu when its needed.
I agree. Tasks that voluntarily relinquish their timeslices should get lower
latency compared to other proc
David Schwartz wrote:
> Good interactivity for tasks that aren't themselves CPU hogs. A task should
> get low latency if and only if it's yielding the CPU voluntarily most of the
> time. If it's not, it can only get better interactivity at the cost of
> fairness, and you have to *ask* for that. (Co
On Mon, 12 Mar 2007 20:06:43 BST, Xavier Bestel said:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for
> > your
> > encoding with one cpu? Is that what other dedicated desktop OSs would do?
>
> One thought o
> "Serge" == Serge Belyshev <[EMAIL PROTECTED]> writes:
Serge> Mike Galbraith <[EMAIL PROTECTED]> writes:
Serge> [snip]
>> It seems to be a plain linear slowdown. The lurchiness I'm experiencing
>> varies in intensity, and is impossible to quantify. I see neither
>> lurchiness nor slowdown i
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression t
On Tue, Mar 13, 2007 at 10:33:18AM +0100, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
>
> > Con, we want RSDL to /improve/ interactivity. Having new scheduler
> > interactivity logic that behaves /worse/ in the presence of CPU hogs,
> > which CPU hogs are even r
On Tue, 2007-03-13 at 14:41 +0300, Serge Belyshev wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> [snip]
> > It seems to be a plain linear slowdown. The lurchiness I'm experiencing
> > varies in intensity, and is impossible to quantify. I see neither
> > lurchiness nor slowdown in mainli
Mike Galbraith <[EMAIL PROTECTED]> writes:
[snip]
> It seems to be a plain linear slowdown. The lurchiness I'm experiencing
> varies in intensity, and is impossible to quantify. I see neither
> lurchiness nor slowdown in mainline through -j8.
>
Whaa? make -j8 on mainline makes my desktop box com
On Tue, 2007-03-13 at 21:06 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:39, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > I just retested with the encoders at nice 0, and the x/gforce combo is
> > > terrible. [...]
> >
> > ok. So nice levels had nothing to do
On Tue, Mar 13, 2007 at 08:41:05PM +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> > So the question is: if all tasks are on the same nice level, how does,
> > in Mike's test scenario, RSDL behave relative to the current
> > interactivity code?
...
> The only way t
On Tue, 2007-03-13 at 20:31 +1100, Con Kolivas wrote:
> nice on my debian etch seems to choose nice +10 without arguments contrary to
> a previous discussion that said 4 was the default. However 4 is a good value
> to use as a base of sorts.
I don't see why. nice uses +10 by default on all linux
On Tuesday 13 March 2007 20:39, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > I just retested with the encoders at nice 0, and the x/gforce combo is
> > terrible. [...]
>
> ok. So nice levels had nothing to do with it - it's some other
> regression somewhere. How does the van
On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Well I guess you must have missed where I asked him if he would be
> > happy if I changed +5 metrics to do whatever he wanted and he refused
> > to answer me. [...]
>
> I'd say lets keep nice levels ou
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> I just retested with the encoders at nice 0, and the x/gforce combo is
> terrible. [...]
ok. So nice levels had nothing to do with it - it's some other
regression somewhere. How does the vanilla scheduler cope with the
exactly same workload? I.e.
On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
> Con, we want RSDL to /improve/ interactivity. Having new scheduler
> interactivity logic that behaves /worse/ in the presence of CPU hogs,
> which CPU hogs are even reniced to +5, than the current interactivity
> code, is i think a non-sta
On Tuesday 13 March 2007 20:21, Con Kolivas wrote:
> On Tuesday 13 March 2007 19:18, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > [...] The situation as we speak is that you can run cpu intensive
> > > tasks while watching eye-candy. With RSDL, you can't, you feel the
>
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> Well I guess you must have missed where I asked him if he would be
> happy if I changed +5 metrics to do whatever he wanted and he refused
> to answer me. [...]
I'd say lets keep nice levels out of this completely for now - while
they should work _to
On Tuesday 13 March 2007 19:18, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agre
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> > It's not "offensive" to me, it is a behavioral regression. The
> > situation as we speak is that you can run cpu intensive tasks while
> > watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. Doesn't the fact
On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
> ps. please be nice to each other - both of you are long-time
> scheduler contributors who did lots of cool stuff :-)
It's no big deal, Con and I just seem to be oil and water. He'll have
to be oil, because water is already take. *evapo
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> [...] The situation as we speak is that you can run cpu intensive
> tasks while watching eye-candy. With RSDL, you can't, you feel the
> non-interactive load instantly. [...]
i have to agree with Mike that this is a material regression that cannot
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > It has been said that "perfection is the enemy of good". The two
> > interactive tasks receiving 40% cpu while two niced background jobs
> > receive 60% may well be perfect, but it's damn sure not good.
>
> Well, the real problem is really "serv
On Tue, 2007-03-13 at 16:53 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> > It's not "offensive" to me, it is a behavioral regression. The
> > situation as we speak is that you can run cpu intensive tasks while
> > watching eye-candy. With RSDL, you can't, y
On Tue, 2007-03-13 at 17:16 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 17:08, Mike Galbraith wrote:
> > Virtual or physical cores has nothing to do with the interactivity
> > regression I noticed. Two nice 0 tasks which combined used 50% of my
> > box can no longer share that box with tw
On Mon, 12 Mar 2007, Lee Revell wrote:
On 3/12/07, David Lang <[EMAIL PROTECTED]> wrote:
the problem comes when this isn't enough. if you have several CPU hogs on a
system, and they are all around the same priority level, how can the
scheduler
know which one needs the CPU the most for good in
On Tue, 2007-03-13 at 16:53 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> > I'm not trying to be pig-headed. I'm of the opinion that fairness is
> > great... until you strictly enforce it wrt interactive tasks.
>
> How about answering my question then since
On Tuesday 13 March 2007 17:08, Mike Galbraith wrote:
> Virtual or physical cores has nothing to do with the interactivity
> regression I noticed. Two nice 0 tasks which combined used 50% of my
> box can no longer share that box with two nice 5 tasks and receive the
> 50% they need to perform. Th
On Mon, 2007-03-12 at 17:38 -0400, michael chang wrote:
> Perhaps, Mike Galbraith, do you feel that it should be possible to use
> the CPU at 100% for some task and still maintain excellent
> interactivity?
Within reason, yes. Defining "reason" is difficult. As we speak, this
is possible to a m
On Tuesday 13 March 2007 00:53, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> > On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> > > On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > > As soon as your cpu is fully utilized, fairness looses or
> > > >
On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> > On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > As soon as your cpu is fully utilized, fairness looses or interactivity
> > > loses. Pick one.
> >
> > That's not true unle
On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > As soon as your cpu is fully utilized, fairness looses or interactivity
> > loses. Pick one.
>
> That's not true unless you refuse to prioritise your tasks
> accordingly. Let's take
On Mar 12, 2007, at 11:26:25, Linus Torvalds wrote:
So "good fairness" really should involve some notion of "work done
for others". It's just not very easy to do..
Maybe extend UNIX sockets to add another passable object type vis-a-
vis SCM_RIGHTS, except in this case "SCM_CPUTIME". You call
On 3/12/07, David Lang <[EMAIL PROTECTED]> wrote:
the problem comes when this isn't enough. if you have several CPU hogs on a
system, and they are all around the same priority level, how can the scheduler
know which one needs the CPU the most for good interactivity?
in some cases you may be able
On 3/12/07, michael chang <[EMAIL PROTECTED]> wrote:
Considering the concepts put out by projects such as BOINC and
[EMAIL PROTECTED], I wouldn't be thoroughly surprised by this ideology,
although I do question the particular way this test case is being run.
If Con actually implements SCHED_ID
On Mon, 12 Mar 2007, Mike Galbraith wrote:
On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
Killing the known corner case starvation scenarios is wonderful, but
let's not just pretend that interactive tasks don't have any special
requ
On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't
On Tue, 2007-03-13 at 00:05 +0300, Serge Belyshev wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> [snip]
> >> And let's not lose sight of things with this one testcase.
> >>
> >> RSDL fixes
> >> - every starvation case
> >> - all fairness isssues
> >> - is better 95% of the time on the de
On 3/12/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> > On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > > Mike the c
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
Mike Galbraith <[EMAIL PROTECTED]> writes:
[snip]
>> And let's not lose sight of things with this one testcase.
>>
>> RSDL fixes
>> - every starvation case
>> - all fairness isssues
>> - is better 95% of the time on the desktop
>
> I don't know where you got that 95% number from. For the most pa
On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have any special
> > requirements.
>
> Now you're reall
On Mon, 2007-03-12 at 21:11 +0100, Mike Galbraith wrote:
> How would you go about ensuring that there won't be any cycles wasted?
SCHED_IDLE or otherwise nice 19
> Killing the known corner case starvation scenarios is wonderful, but
> let's not just pretend that interactive tasks don't have any
On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> > On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > > Mike the cpu is being proportioned out perfectly according to
>
On Mon, 2007-03-12 at 08:26 -0700, Linus Torvalds wrote:
>
> On Mon, 12 Mar 2007, Mike Galbraith wrote:
> >
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> >
> > > Mike the cpu is being proportioned out perfectly according to fairness as
> > > I
> > > mentioned in the prior email, y
On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > Mike the cpu is being proportioned out perfectly according to fairness as
> > > I mentioned in the prior email, yet X is gett
Xavier Bestel wrote:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for
> > your encoding with one cpu? Is that what other dedicated desktop OSs
> > would do?
>
> as your scheduler
> is "strictly fair", won't tha
On Mon, 2007-03-12 at 08:26 -0700, Linus Torvalds wrote:
> So "good fairness" really should involve some notion of "work done for
> others". It's just not very easy to do..
A solution that is already in demand is a class based scheduler, where
the thread doing work for a client (temp.) joins the
Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> Again I think your test is not a valid testcase. Why use two threads for your
> encoding with one cpu? Is that what other dedicated desktop OSs would do?
One thought occured to me (shit happens, sometimes): as your scheduler
is "strictl
On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > Mike the cpu is being proportioned out perfectly according to fairness as
> > I mentioned in the prior email, yet X is getting the lower latency
> > scheduling. I'm not sure within the
On Monday 12 March 2007, Gene Heskett wrote:
>On Monday 12 March 2007, Con Kolivas wrote:
>>On 12/03/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>>> On Monday 12 March 2007, Gene Heskett wrote:
>>> >To Con, I knew 2.6.20 worked with your earlier patches, so rather
>>> > than revert all the way, I j
On Tuesday 13 March 2007 00:48, Theodore Tso wrote:
> On Mon, Mar 12, 2007 at 10:23:06PM +1100, Con Kolivas wrote:
> > > > > We are getting good interactive response with a fair scheduler yet
> > > > > you seem intent on overloading it to find fault with it.
> > > >
> > > > I'm not trying to find f
On Tuesday 13 March 2007 02:26, Linus Torvalds wrote:
> On Mon, 12 Mar 2007, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > Mike the cpu is being proportioned out perfectly according to fairness
> > > as I mentioned in the prior email, yet X is getting the low
On Mon, 2007-03-12 at 21:34 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Xavier Bestel wrote:
> > On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > > Hmm. So... anything that's client/server is going to suffer horri
On Monday 12 March 2007, Con Kolivas wrote:
>On 12/03/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>> On Monday 12 March 2007, Gene Heskett wrote:
>> >To Con, I knew 2.6.20 worked with your earlier patches, so rather
>> > than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and
>> > I'm go
On Mon, 12 Mar 2007, Mike Galbraith wrote:
>
> On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
>
> > Mike the cpu is being proportioned out perfectly according to fairness as I
> > mentioned in the prior email, yet X is getting the lower latency
> > scheduling.
> > I'm not sure within t
On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> Mike the cpu is being proportioned out perfectly according to fairness as I
> mentioned in the prior email, yet X is getting the lower latency scheduling.
> I'm not sure within the bounds of fairness what more would you have happen to
> yo
On Mon, Mar 12, 2007 at 10:23:06PM +1100, Con Kolivas wrote:
> > > > We are getting good interactive response with a fair scheduler yet
> > > > you seem intent on overloading it to find fault with it.
> > >
> > > I'm not trying to find fault, I'm TESTING AND REPORTING. Was.
> >
> > Con, could you
On 12/03/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
On Monday 12 March 2007, Gene Heskett wrote:
>To Con, I knew 2.6.20 worked with your earlier patches, so rather than
>revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going
>to fire off another backup. I suspect it will work,
On Monday 12 March 2007, Gene Heskett wrote:
>On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
>>On 3/11/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>>> On Sunday 11 March 2007, Mike Galbraith wrote:
>>>
>>> Just to comment, I've been running one of the patches between 20-ck1
>>> and this lates
On Mon, 2007-03-12 at 12:08 +0100, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > The test scenario was one any desktop user might do with every
> > expectation responsiveness of the interactive application remain
> > intact. I understand the concepts here Con, and I'm no
On Monday 12 March 2007 22:08, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > The test scenario was one any desktop user might do with every
> > expectation responsiveness of the interactive application remain
> > intact. I understand the concepts here Con, and I'm not knockin
On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
>On 3/11/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>> On Sunday 11 March 2007, Mike Galbraith wrote:
>>
>> Just to comment, I've been running one of the patches between 20-ck1
>> and this latest one, which is building as I type, but I also run
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> The test scenario was one any desktop user might do with every
> expectation responsiveness of the interactive application remain
> intact. I understand the concepts here Con, and I'm not knocking your
> scheduler. I find it to be a step forward on
On Mon, 2007-03-12 at 21:27 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> >
> Now I think you're getting carried away because of your expectations from the
> previous scheduler and its woefully unfair treatment towards interactive
> tasks. Look at how you're
On Monday 12 March 2007 20:38, Xavier Bestel wrote:
> On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > Hmm. So... anything that's client/server is going to suffer horribly
> > > unless niced tasks are niced all the way down to 19?
On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > > I'll save you the trouble. I just checked myself and indeed the l
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > Hmm. So... anything that's client/server is going to suffer horribly
> > unless niced tasks are niced all the way down to 19?
>
> Fortunately most client server models dont usually hav
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > I'll save you the trouble. I just checked myself and indeed the load is
> > > only 1. What this means is that although there a
On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > I'll save you the trouble. I just checked myself and indeed the load is
> > only 1. What this means is that although there are 2 tasks running, only
> > one is running at any time making
On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> I'll save you the trouble. I just checked myself and indeed the load is only
> 1. What this means is that although there are 2 tasks running, only one is
> running at any time making a total load of 1. So, if we add two other tasks
> that
On Mon, 2007-03-12 at 18:48 +1100, Con Kolivas wrote:
>
> Just a couple of questions;
>
> The X/Gforce case; do they alternate cpu between them? By that I mean when
> they're the only thing running does the cpu load summate to 1 or does it
> summate to 2?
They're each on their own cpu (sibling
On Monday 12 March 2007 18:48, Con Kolivas wrote:
> On Monday 12 March 2007 18:22, Mike Galbraith wrote:
> > On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> > > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > > > Full patch for 2.6.21-rc3-mm2:
> > > > > http://ck.kolivas.org/patches/stair
On Monday 12 March 2007 18:22, Mike Galbraith wrote:
> On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > > Full patch for 2.6.21-rc3-mm2:
> > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-
> > > >0.29.patch
> > >
>
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > > Full patch for 2.6.21-rc3-mm2:
> > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
> >
> > I'm seeing a cpu distribution problem running this on my P4 box
On 3/11/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
On Sunday 11 March 2007, Mike Galbraith wrote:
Just to comment, I've been running one of the patches between 20-ck1 and
this latest one, which is building as I type, but I also run gkrellm
here, version 2.2.9.
Since I have been running this mi
On Sun, 2007-03-11 at 13:20 +0100, Mike Galbraith wrote:
> I'll boot up nosmp and report back
Hohum. nosmp doesn't boot (locks after ide [bla] IRQ 14), will
recompile UP in the A.M. and try again.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Sunday 11 March 2007, Mike Galbraith wrote:
>Hi Con,
>
>On Sun, 2007-03-11 at 14:57 +1100, Con Kolivas wrote:
>> What follows this email is a patch series for the latest version of
>> the RSDL cpu scheduler (ie v0.29). I have addressed all bugs that I am
>> able to reproduce in this version so i
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > > Full patch for 2.6.21-rc3-mm2:
> > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
> >
> > I'm seeing a cpu distribution problem running this on my P4 box
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > Full patch for 2.6.21-rc3-mm2:
> > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
>
> I'm seeing a cpu distribution problem running this on my P4 box.
> With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain sm
On Sun, 2007-03-11 at 22:48 +1100, Con Kolivas wrote:
>
> Thanks for the report. I'm assuming you're describing a single hyperthread P4
> here in SMP mode so 2 logical cores. Can you elaborate on whether there is
> any difference as to which cpu things are bound to as well? Can you also see
> w
On Sunday 11 March 2007 22:39, Mike Galbraith wrote:
> Hi Con,
>
> On Sun, 2007-03-11 at 14:57 +1100, Con Kolivas wrote:
> > What follows this email is a patch series for the latest version of the
> > RSDL cpu scheduler (ie v0.29). I have addressed all bugs that I am able
> > to reproduce in this v
Hi Con,
On Sun, 2007-03-11 at 14:57 +1100, Con Kolivas wrote:
> What follows this email is a patch series for the latest version of the RSDL
> cpu scheduler (ie v0.29). I have addressed all bugs that I am able to
> reproduce in this version so if some people would be kind enough to test if
> th
90 matches
Mail list logo