Alberto Gonzalez wrote:
On Saturday 23 June 2007, Tom Spink wrote:
Alberto,
If you're feeling adventurous, grab the latest kernel and patch it
with Ingo's scheduler: CFS.
You may be pleasantly surprised.
Thanks, I might if I have to courage to patch and compile my own kernel :)
However,
On Saturday 23 June 2007, Kyle Moffett wrote:
> On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
> > P.S: As a second thought, a fair scheduler could behave really good
> > in other scenarios, like a server running a busy forum on apache
> > +mysql+php. Besides, this is a more real world
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
P.S: As a second thought, a fair scheduler could behave really good
in other scenarios, like a server running a busy forum on apache
+mysql+php. Besides, this is a more real world scenario
Alberto Gonzalez wrote:
On Saturday 23 June 2007, Tom Spink wrote:
Alberto,
If you're feeling adventurous, grab the latest kernel and patch it
with Ingo's scheduler: CFS.
You may be pleasantly surprised.
Thanks, I might if I have to courage to patch and compile my own kernel :)
However,
Alberto Gonzalez wrote:
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Ok, so what will a fair scheduler do in this case? It is my
understanding that it would give 50% CPU to each task, resulting in
the video dropping frames. Is this
Alberto Gonzalez wrote:
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Ok, so what will a fair scheduler do in this case? It is my
understanding that it would give 50% CPU to each task, resulting in
the video dropping frames. Is this
On 23/06/07, Alberto Gonzalez <[EMAIL PROTECTED]> wrote:
El Saturday 23 June 2007 18:35:18 Kyle Moffett escribió:
[snip]
> "PROCESS1 is more important than PROCESS2" is pure policy and must be
> done from userspace. We even give appropriate enforcement mechanisms
> to userspace to take such
Alberto Gonzalez wrote:
> On Saturday 23 June 2007, Kyle Moffett wrote:
> > On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
> > What this *actually* means is that you want the media player to have
> > higher priority than the DVD ripping program. Ergo you should run
> > "nice +20
Alberto Gonzalez wrote:
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
What this *actually* means is that you want the media player to have
higher priority than the DVD ripping program. Ergo you should run
nice +20 my_dvd_burner or
On 23/06/07, Alberto Gonzalez [EMAIL PROTECTED] wrote:
El Saturday 23 June 2007 18:35:18 Kyle Moffett escribió:
[snip]
PROCESS1 is more important than PROCESS2 is pure policy and must be
done from userspace. We even give appropriate enforcement mechanisms
to userspace to take such action
El Saturday 23 June 2007 18:35:18 Kyle Moffett escribió:
> If you want the kernel to
> treat one job or the other as more important then you must *TELL* it
> that, end of story.
Yes, that makes sense now that it's been explained to me conveniently. As long
as a normal user is not left alone with
On Jun 23, 2007, at 03:46:43, Alberto Gonzalez wrote:
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Ok, so what will a fair scheduler do in this case? It is my
understanding that it would give 50% CPU to each task, resulting
in the video
On Sat, 23 Jun 2007 15:56:36 +0200
Alberto Gonzalez <[EMAIL PROTECTED]> wrote:
> > And yes, programs/distributions should set good defaults for you... and
> > if they don't, just complain to them :)
>
> I'm sure they'll do once a fair scheduler goes into mainline :)
Some already does... for
On Saturday 23 June 2007, Paolo Ornati wrote:
> But the fact is, the "interactivity estimator" is too fragile, and when
> it fails it can do much damage.
>
>
> Fair scheduler instead:
> - are robust
> - provide consistent behaviour
> - provide good interactivity within the bounds
On Sat, 23 Jun 2007 10:01:02 +0200
Alberto Gonzalez <[EMAIL PROTECTED]> wrote:
> I see. So you mean that in 90% of the cases the mainline scheduler behaves
> better than fair schedulers, but when its "logic" fails it behaves much worse
> (the other 10% cases)?
Yes and no... the "logic" is
On Sat, Jun 23, 2007 at 01:26:34PM +0200, Alberto Gonzalez wrote:
> On Saturday 23 June 2007, Tom Spink wrote:
> > Alberto,
> >
> > If you're feeling adventurous, grab the latest kernel and patch it
> > with Ingo's scheduler: CFS.
> >
> > You may be pleasantly surprised.
>
> Thanks, I might if I
On Saturday 23 June 2007, Tom Spink wrote:
> Alberto,
>
> If you're feeling adventurous, grab the latest kernel and patch it
> with Ingo's scheduler: CFS.
>
> You may be pleasantly surprised.
Thanks, I might if I have to courage to patch and compile my own kernel :)
However, I'd also need to
On 23/06/07, Alberto Gonzalez <[EMAIL PROTECTED]> wrote:
On Saturday 23 June 2007, Willy Tarreau wrote:
> On Sat, Jun 23, 2007 at 12:45:30PM +0200, Alberto Gonzalez wrote:
> > Ok, so if I understand correctly, the problem I had in my simple test
> > will be solved by distributions once a fair
On Saturday 23 June 2007, Willy Tarreau wrote:
> On Sat, Jun 23, 2007 at 12:45:30PM +0200, Alberto Gonzalez wrote:
> > Ok, so if I understand correctly, the problem I had in my simple test
> > will be solved by distributions once a fair scheduler goes into mainline?
>
> No, there is no reason to
On Sat, Jun 23, 2007 at 12:45:30PM +0200, Alberto Gonzalez wrote:
> On Saturday 23 June 2007, Willy Tarreau wrote:
>
> > > But the bottom line is that on a desktop, tasks should receive
> > > different -unfair- amounts of CPU time to work correctly. The "fair"
> > > concept still looks wrong to
On Saturday 23 June 2007, Willy Tarreau wrote:
> > But the bottom line is that on a desktop, tasks should receive
> > different -unfair- amounts of CPU time to work correctly. The "fair"
> > concept still looks wrong to me.
>
> "fair" means what it means : stop starving some tasks for no apparent
On Sat, Jun 23, 2007 at 11:18:43AM +0200, Alberto Gonzalez wrote:
> On Saturday 23 June 2007, Willy Tarreau wrote:
> > On Sat, Jun 23, 2007 at 10:01:02AM +0200, Alberto Gonzalez wrote:
> > > I see. So you mean that in 90% of the cases the mainline scheduler
> > > behaves better than fair
I think you're not considering normal users here. Believe it or not, 99% of
desktop users in the world just click on a icon to watch a video. And they DO
want watch them, not use them for monitoring purposes (whatever that means).
I acknowledge it's impossible to be inside a user's mind to
On Saturday 23 June 2007, Willy Tarreau wrote:
> On Sat, Jun 23, 2007 at 10:01:02AM +0200, Alberto Gonzalez wrote:
> > I see. So you mean that in 90% of the cases the mainline scheduler
> > behaves better than fair schedulers, but when its "logic" fails it
> > behaves much worse (the other 10%
On Sat, Jun 23, 2007 at 10:01:02AM +0200, Alberto Gonzalez wrote:
> Thanks for your thoughts.
>
> On Saturday 23 June 2007, Paolo Ornati wrote:
> > On Sat, 23 Jun 2007 00:07:15 +0200
> >
> > Alberto Gonzalez wrote:
> > > My conclusion is that SD behaves as expected: it's more fair. But for a
> >
Thanks for your thoughts.
On Saturday 23 June 2007, Paolo Ornati wrote:
> On Sat, 23 Jun 2007 00:07:15 +0200
>
> Alberto Gonzalez wrote:
> > My conclusion is that SD behaves as expected: it's more fair. But for a
> > desktop, shouldn't an "intelligently unfair" scheduler be better?
>
>
On Saturday 23 June 2007, Kyle Moffett wrote:
> On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
> > Ok, so what will a fair scheduler do in this case? It is my
> > understanding that it would give 50% CPU to each task, resulting in
> > the video dropping frames. Is this correct?
>
> Yes,
On Sat, 23 Jun 2007 00:07:15 +0200
Alberto Gonzalez <[EMAIL PROTECTED]> wrote:
> My conclusion is that SD behaves as expected: it's more fair. But for a
> desktop, shouldn't an "intelligently unfair" scheduler be better?
"intelligently unfair" is what the current scheduler is (because of
On Sat, 23 Jun 2007 00:07:15 +0200
Alberto Gonzalez [EMAIL PROTECTED] wrote:
My conclusion is that SD behaves as expected: it's more fair. But for a
desktop, shouldn't an intelligently unfair scheduler be better?
intelligently unfair is what the current scheduler is (because of
interactivity
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Ok, so what will a fair scheduler do in this case? It is my
understanding that it would give 50% CPU to each task, resulting in
the video dropping frames. Is this correct?
Yes, that's
On Sat, Jun 23, 2007 at 10:01:02AM +0200, Alberto Gonzalez wrote:
Thanks for your thoughts.
On Saturday 23 June 2007, Paolo Ornati wrote:
On Sat, 23 Jun 2007 00:07:15 +0200
Alberto Gonzalez wrote:
My conclusion is that SD behaves as expected: it's more fair. But for a
desktop,
Thanks for your thoughts.
On Saturday 23 June 2007, Paolo Ornati wrote:
On Sat, 23 Jun 2007 00:07:15 +0200
Alberto Gonzalez wrote:
My conclusion is that SD behaves as expected: it's more fair. But for a
desktop, shouldn't an intelligently unfair scheduler be better?
intelligently unfair
On Saturday 23 June 2007, Willy Tarreau wrote:
On Sat, Jun 23, 2007 at 10:01:02AM +0200, Alberto Gonzalez wrote:
I see. So you mean that in 90% of the cases the mainline scheduler
behaves better than fair schedulers, but when its logic fails it
behaves much worse (the other 10% cases)? In
I think you're not considering normal users here. Believe it or not, 99% of
desktop users in the world just click on a icon to watch a video. And they DO
want watch them, not use them for monitoring purposes (whatever that means).
I acknowledge it's impossible to be inside a user's mind to
On Sat, Jun 23, 2007 at 12:45:30PM +0200, Alberto Gonzalez wrote:
On Saturday 23 June 2007, Willy Tarreau wrote:
But the bottom line is that on a desktop, tasks should receive
different -unfair- amounts of CPU time to work correctly. The fair
concept still looks wrong to me.
fair
On Sat, Jun 23, 2007 at 11:18:43AM +0200, Alberto Gonzalez wrote:
On Saturday 23 June 2007, Willy Tarreau wrote:
On Sat, Jun 23, 2007 at 10:01:02AM +0200, Alberto Gonzalez wrote:
I see. So you mean that in 90% of the cases the mainline scheduler
behaves better than fair schedulers, but
On Saturday 23 June 2007, Willy Tarreau wrote:
But the bottom line is that on a desktop, tasks should receive
different -unfair- amounts of CPU time to work correctly. The fair
concept still looks wrong to me.
fair means what it means : stop starving some tasks for no apparent
reasons.
On 23/06/07, Alberto Gonzalez [EMAIL PROTECTED] wrote:
On Saturday 23 June 2007, Willy Tarreau wrote:
On Sat, Jun 23, 2007 at 12:45:30PM +0200, Alberto Gonzalez wrote:
Ok, so if I understand correctly, the problem I had in my simple test
will be solved by distributions once a fair scheduler
On Saturday 23 June 2007, Willy Tarreau wrote:
On Sat, Jun 23, 2007 at 12:45:30PM +0200, Alberto Gonzalez wrote:
Ok, so if I understand correctly, the problem I had in my simple test
will be solved by distributions once a fair scheduler goes into mainline?
No, there is no reason to wait for
On Saturday 23 June 2007, Tom Spink wrote:
Alberto,
If you're feeling adventurous, grab the latest kernel and patch it
with Ingo's scheduler: CFS.
You may be pleasantly surprised.
Thanks, I might if I have to courage to patch and compile my own kernel :)
However, I'd also need to change
On Sat, Jun 23, 2007 at 01:26:34PM +0200, Alberto Gonzalez wrote:
On Saturday 23 June 2007, Tom Spink wrote:
Alberto,
If you're feeling adventurous, grab the latest kernel and patch it
with Ingo's scheduler: CFS.
You may be pleasantly surprised.
Thanks, I might if I have to courage
On Sat, 23 Jun 2007 10:01:02 +0200
Alberto Gonzalez [EMAIL PROTECTED] wrote:
I see. So you mean that in 90% of the cases the mainline scheduler behaves
better than fair schedulers, but when its logic fails it behaves much worse
(the other 10% cases)?
Yes and no... the logic is supposed to
On Jun 23, 2007, at 03:46:43, Alberto Gonzalez wrote:
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Ok, so what will a fair scheduler do in this case? It is my
understanding that it would give 50% CPU to each task, resulting
in the video
On Saturday 23 June 2007, Paolo Ornati wrote:
But the fact is, the interactivity estimator is too fragile, and when
it fails it can do much damage.
Fair scheduler instead:
- are robust
- provide consistent behaviour
- provide good interactivity within the bounds of
On Sat, 23 Jun 2007 15:56:36 +0200
Alberto Gonzalez [EMAIL PROTECTED] wrote:
And yes, programs/distributions should set good defaults for you... and
if they don't, just complain to them :)
I'm sure they'll do once a fair scheduler goes into mainline :)
Some already does... for example
El Saturday 23 June 2007 18:35:18 Kyle Moffett escribió:
If you want the kernel to
treat one job or the other as more important then you must *TELL* it
that, end of story.
Yes, that makes sense now that it's been explained to me conveniently. As long
as a normal user is not left alone with
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Let's say I have a HD video that uses ~70% CPU. Let's say I want to
watch it while I encode my music to vorbis (or rip a DVD). This is
the only reasonable scenario I can imagine on a normal desktop,
since most desktops have the CPU idle
Hi,
First I'd like to say I'm not a programmer or even a geek, just a normal user,
so my question might be very basic or even stupid. If so, please excuse me.
I've been reading about CFS and SD schedulers here on the list and my basic
understanding is that they try to improve interactivity by
Hi,
First I'd like to say I'm not a programmer or even a geek, just a normal user,
so my question might be very basic or even stupid. If so, please excuse me.
I've been reading about CFS and SD schedulers here on the list and my basic
understanding is that they try to improve interactivity by
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Let's say I have a HD video that uses ~70% CPU. Let's say I want to
watch it while I encode my music to vorbis (or rip a DVD). This is
the only reasonable scenario I can imagine on a normal desktop,
since most desktops have the CPU idle
50 matches
Mail list logo
