Bill Huey (hui) wrote:
On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote:
Dunno. I guess a lot of people would like to then manage the classes,
which would be painful as hell.
Sure ! I wouldn't like people to point the finger on Linux saying "hey
look, they can't write a good
On Mon, 19 Mar 2007, Radoslaw Szkodzinski wrote:
Consider two servers,
^ ^ ^
Well, aren't we discussing desktops?
Server admins can fine-tune the rights and CPU quotas per group.
how many multi-user desktops are there? most desktops that I have seen run just
about everything as a single
Helge Hafting wrote:
Avi Kivity wrote:
A fairly contrived example, but I see your point. Of course any
system can be broken. I think that user-level scheduling is good for
real multi user systems, where 'user' means a person, not an
artificial entity. It's also good for a multi
Avi Kivity wrote:
A fairly contrived example, but I see your point. Of course any
system can be broken. I think that user-level scheduling is good for
real multi user systems, where 'user' means a person, not an
artificial entity. It's also good for a multi application server,
where
[what happened to the 'To' header?]
David Schwartz wrote:
I didn't suggest adding any unfairness! I suggested being fair by
user/job/process instead of being fair by thread (which is actually
unfair as it favors multi threaded processes over single threaded
processes).
Wouldn't that be
On 3/19/07, David Schwartz <[EMAIL PROTECTED]> wrote:
> I didn't suggest adding any unfairness! I suggested being fair by
> user/job/process instead of being fair by thread (which is actually
> unfair as it favors multi threaded processes over single threaded
> processes).
Wouldn't that be
On 3/19/07, David Schwartz [EMAIL PROTECTED] wrote:
I didn't suggest adding any unfairness! I suggested being fair by
user/job/process instead of being fair by thread (which is actually
unfair as it favors multi threaded processes over single threaded
processes).
Wouldn't that be unfair
[what happened to the 'To' header?]
David Schwartz wrote:
I didn't suggest adding any unfairness! I suggested being fair by
user/job/process instead of being fair by thread (which is actually
unfair as it favors multi threaded processes over single threaded
processes).
Wouldn't that be
Avi Kivity wrote:
A fairly contrived example, but I see your point. Of course any
system can be broken. I think that user-level scheduling is good for
real multi user systems, where 'user' means a person, not an
artificial entity. It's also good for a multi application server,
where
Helge Hafting wrote:
Avi Kivity wrote:
A fairly contrived example, but I see your point. Of course any
system can be broken. I think that user-level scheduling is good for
real multi user systems, where 'user' means a person, not an
artificial entity. It's also good for a multi
On Mon, 19 Mar 2007, Radoslaw Szkodzinski wrote:
Consider two servers,
^ ^ ^
Well, aren't we discussing desktops?
Server admins can fine-tune the rights and CPU quotas per group.
how many multi-user desktops are there? most desktops that I have seen run just
about everything as a single
Bill Huey (hui) wrote:
On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote:
Dunno. I guess a lot of people would like to then manage the classes,
which would be painful as hell.
Sure ! I wouldn't like people to point the finger on Linux saying hey
look, they can't write a good
> I didn't suggest adding any unfairness! I suggested being fair by
> user/job/process instead of being fair by thread (which is actually
> unfair as it favors multi threaded processes over single threaded
> processes).
Wouldn't that be unfair because it favors multi-user approaches over
Op Sunday 18 March 2007, schreef Mike Galbraith:
> On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
> > Now for something constructive... by any chance is Mike running KDE
> > instead of GNOME?
>
> Yes.
>
> -Mike
Well, then, it might indeed be the KIOslave/pipe stuff. I experience
Willy Tarreau wrote:
The per-user system would also be nice for servers, provided there are
CPU/disc IO/swapper/... quotas or priorities at least.
This is too hard to adjust. Imagine what would happen to your hundreds of
apache processes when the "backup" user will start the rsync or
On Sun, Mar 18, 2007 at 07:54:20AM +0100, Radoslaw Szkodzinski wrote:
> On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> >On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:
> >
> >> Maybe we're all discussing the problem because we have reached the point
> >> where we need two types of
On Sun, Mar 18, 2007 at 07:37:02AM +0100, Mike Galbraith wrote:
> On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote:
>
> > Like I've said in a previous email, SGI schedulers have an interactive
> > term in addition to the normal "nice" values. If RSDL ends up being too
> > rigid for desktop use,
On Sun, Mar 18, 2007 at 07:37:02AM +0100, Mike Galbraith wrote:
On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote:
Like I've said in a previous email, SGI schedulers have an interactive
term in addition to the normal nice values. If RSDL ends up being too
rigid for desktop use, then this
On Sun, Mar 18, 2007 at 07:54:20AM +0100, Radoslaw Szkodzinski wrote:
On 3/18/07, Mike Galbraith [EMAIL PROTECTED] wrote:
On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:
Maybe we're all discussing the problem because we have reached the point
where we need two types of schedulers :
Willy Tarreau wrote:
The per-user system would also be nice for servers, provided there are
CPU/disc IO/swapper/... quotas or priorities at least.
This is too hard to adjust. Imagine what would happen to your hundreds of
apache processes when the backup user will start the rsync or
Op Sunday 18 March 2007, schreef Mike Galbraith:
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
Now for something constructive... by any chance is Mike running KDE
instead of GNOME?
Yes.
-Mike
Well, then, it might indeed be the KIOslave/pipe stuff. I experience sometimes
I didn't suggest adding any unfairness! I suggested being fair by
user/job/process instead of being fair by thread (which is actually
unfair as it favors multi threaded processes over single threaded
processes).
Wouldn't that be unfair because it favors multi-user approaches over
On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:
> Maybe we're all discussing the problem because we have reached the point
> where we need two types of schedulers : one for the desktop and one for
> the servers. After all, this is
On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote:
> Like I've said in a previous email, SGI schedulers have an interactive
> term in addition to the normal "nice" values. If RSDL ends up being too
> rigid for desktop use, then this might be a good idea to explore in
> addition to priority
On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:
> Maybe we're all discussing the problem because we have reached the point
> where we need two types of schedulers : one for the desktop and one for
> the servers. After all, this is already what is proposed with preempt,
> it would make
On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote:
> > Dunno. I guess a lot of people would like to then manage the classes,
> > which would be painful as hell.
>
> Sure ! I wouldn't like people to point the finger on Linux saying "hey
> look, they can't write a good scheduler so
Willy Tarreau wrote:
On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote:
On Sat, 17 Mar 2007, William Lee Irwin III wrote:
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc.
Doing some "classing" even by just
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
> Now for something constructive... by any chance is Mike running KDE
> instead of GNOME?
Yes.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 17 Mar 2007, William Lee Irwin III wrote:
> >
> > One issue this raises is prioritizing users on a system, threads within
> > processes, jobs within users, etc.
>
> Doing some "classing" even by just euid might be a
William Lee Irwin III wrote:
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
> Con Kolivas wrote:
>
> Now for something constructive... by any chance is Mike running KDE
> instead of GNOME? I only had a short time to play because I had to look
> at another problem in 2.6.21-rc3 (nbd not working), so the test
Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
You initially said you were pleased with
_any_. [...]
and i showed you a workload under _RSDL_ that clearly shows that RSDL is
an unfair scheduler too.
my whole point was to counter the myth of 'RSDL has no heuristics'. Of
course it has heuristics, which results in unfairness. (If it didnt have
any heuristics that tilt the balance of sche
On Sat, 17 Mar 2007, William Lee Irwin III wrote:
>
> One issue this raises is prioritizing users on a system, threads within
> processes, jobs within users, etc.
Doing some "classing" even by just euid might be a good idea. It would
actually catch X automatically most of the time, because
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
> Well, the heuristic here is that process == job. I'm not sure heuristic
> is the right name for it, but it does point out a deficieny.
> A cpu-bound process with many threads will overwhelm a cpu-bound single
> threaded threaded
Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the design! Let me
Miell; Linus Torvalds; Andrew
> Morton
> Subject: Re: [ck] Re: is RSDL an "unfair" scheduler too?
>
>
> Op Saturday 17 March 2007, schreef Con Kolivas:
> > On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
> > > * Con Kolivas <[EMAIL PROTECTED]> wrote:
&g
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
> You initially said you were pleased with this design.
I said
o this claim of yours:
> > > Despite the claims to the contrary, RSDL does not have _less_
> > > heuristics, it does not have _any_. [...]
>
> and i showed you a workload under _RSDL_ that clearly shows that RSDL is
> an unfair scheduler too.
>
> my whole point was to counte
howed you a workload under _RSDL_ that clearly shows that RSDL is
an unfair scheduler too.
my whole point was to counter the myth of 'RSDL has no heuristics'. Of
course it has heuristics, which results in unfairness. (If it didnt have
any heuristics that tilt the balance of scheduling towards sl
Op Saturday 17 March 2007, schreef Con Kolivas:
> On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
> > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > Despite the claims to the contrary, RSDL does not have _less_
> > > heuristics, it does not have _any_. It's purely entitlement based.
> >
> >
Op Saturday 17 March 2007, schreef Ingo Molnar:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Despite the claims to the contrary, RSDL does not have _less_
> > heuristics, it does not have _any_. It's purely entitlement based.
>
> RSDL still has heuristics very much, but this time it's hardcoded
On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Despite the claims to the contrary, RSDL does not have _less_
> > heuristics, it does not have _any_. It's purely entitlement based.
>
> RSDL still has heuristics very much, but this time it's
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> Despite the claims to the contrary, RSDL does not have _less_
> heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the design! Let me demonstrate this via a simple
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the design! Let me demonstrate this via a simple
On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
Op Saturday 17 March 2007, schreef Ingo Molnar:
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the
Op Saturday 17 March 2007, schreef Con Kolivas:
On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has
shows that RSDL is
an unfair scheduler too.
my whole point was to counter the myth of 'RSDL has no heuristics'. Of
course it has heuristics, which results in unfairness. (If it didnt have
any heuristics that tilt the balance of scheduling towards sleep-intense
tasks then a default Linux desktop
. [...]
and i showed you a workload under _RSDL_ that clearly shows that RSDL is
an unfair scheduler too.
my whole point was to counter the myth of 'RSDL has no heuristics'. Of
course it has heuristics, which results in unfairness. (If it didnt have
any heuristics that tilt the balance
* Con Kolivas [EMAIL PROTECTED] wrote:
Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
You initially said you were pleased with this design.
I said
Morton
Subject: Re: [ck] Re: is RSDL an unfair scheduler too?
Op Saturday 17 March 2007, schreef Con Kolivas:
On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does
Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the design! Let me
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound single
threaded threaded process.
On Sat, 17 Mar 2007, William Lee Irwin III wrote:
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc.
Doing some classing even by just euid might be a good idea. It would
actually catch X automatically most of the time, because the
. [...]
and i showed you a workload under _RSDL_ that clearly shows that RSDL is
an unfair scheduler too.
my whole point was to counter the myth of 'RSDL has no heuristics'. Of
course it has heuristics, which results in unfairness. (If it didnt have
any heuristics that tilt the balance of scheduling
Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
You initially said you were pleased with
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
Con Kolivas wrote:
snip
Now for something constructive... by any chance is Mike running KDE
instead of GNOME? I only had a short time to play because I had to look
at another problem in 2.6.21-rc3 (nbd not working), so the test
William Lee Irwin III wrote:
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
Well, the heuristic here is that process == job. I'm not sure heuristic
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound
On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote:
On Sat, 17 Mar 2007, William Lee Irwin III wrote:
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc.
Doing some classing even by just euid might be a good idea. It
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
Now for something constructive... by any chance is Mike running KDE
instead of GNOME?
Yes.
-Mike
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Willy Tarreau wrote:
On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote:
On Sat, 17 Mar 2007, William Lee Irwin III wrote:
One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc.
Doing some classing even by just euid
On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote:
Dunno. I guess a lot of people would like to then manage the classes,
which would be painful as hell.
Sure ! I wouldn't like people to point the finger on Linux saying hey
look, they can't write a good scheduler so you have
On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:
Maybe we're all discussing the problem because we have reached the point
where we need two types of schedulers : one for the desktop and one for
the servers. After all, this is already what is proposed with preempt,
it would make sense
On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote:
Like I've said in a previous email, SGI schedulers have an interactive
term in addition to the normal nice values. If RSDL ends up being too
rigid for desktop use, then this might be a good idea to explore in
addition to priority
On 3/18/07, Mike Galbraith [EMAIL PROTECTED] wrote:
On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:
Maybe we're all discussing the problem because we have reached the point
where we need two types of schedulers : one for the desktop and one for
the servers. After all, this is already
66 matches
Mail list logo