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
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 don't have special
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,
> >
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,
Already is
[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
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
> 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.
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
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
> >
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
> 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
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.
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
> "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
> * 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
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
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
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
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
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
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
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
* 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
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
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
* 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
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.
* 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
* 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
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,
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, you feel
* 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 server that
* 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
be
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.
* 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 that
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 agree with
* 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 _too_,
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
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
* 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 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 out of this
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 vanilla
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 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 to get
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 with it - it's
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
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 mainline through
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 reniced
* 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
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 in mainline through
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 occured
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.
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
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 lower
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
their
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.
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 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
[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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
1 - 100 of 182 matches
Mail list logo
