Process.priority and sheduling
Floris Bruynooghe
In short I'd like to consider putting a FutureWarning on the
Process.priority attribute.
The motivation for this is that it's a bit of a stretch to simply give
the priority of a process. Most systems actually have threads as
schdulable entity so the actual priority applies to a thread and not
the process. Most systems also dynamically adjust this on a
per-thread basis. What tends to be per-process is some sort of
"scheduler class".
Anyway, I don't really care much about priority right now so don't
fancy figuring out what exactly it should be (should we have a Thread
object too, etc?). Therefore I'd like to keep it as it is but add a
FutureWarning so that when we do take the time to sort it out we're
not limited by some strange backwards incompatible stuff.
Toughts, objections?
Floris
PS: Process.nice stays out of this I think as it's not influenced by
dynamic stuff and just applies to the process (on systems supporting
nice).
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Chris Miles
On 29/11/2009, at 2:12 AM, Floris Bruynooghe wrote:
> Hi
>
> In short I'd like to consider putting a FutureWarning on the
> Process.priority attribute.
>
> The motivation for this is that it's a bit of a stretch to simply give
> the priority of a process. Most systems actually have threads as
> schdulable entity so the actual priority applies to a thread and not
> the process. Most systems also dynamically adjust this on a
> per-thread basis. What tends to be per-process is some sort of
> "scheduler class".
>
> Anyway, I don't really care much about priority right now so don't
> fancy figuring out what exactly it should be (should we have a Thread
> object too, etc?). Therefore I'd like to keep it as it is but add a
> FutureWarning so that when we do take the time to sort it out we're
> not limited by some strange backwards incompatible stuff.
>
> Toughts, objections?
>
Cheers
Chris
Floris Bruynooghe
>
> On 29/11/2009, at 2:12 AM, Floris Bruynooghe wrote:
>
> > Hi
> >
> > In short I'd like to consider putting a FutureWarning on the
> > Process.priority attribute.
> >
> > The motivation for this is that it's a bit of a stretch to simply give
> > the priority of a process. Most systems actually have threads as
> > schdulable entity so the actual priority applies to a thread and not
> > the process. Most systems also dynamically adjust this on a
> > per-thread basis. What tends to be per-process is some sort of
> > "scheduler class".
> >
> > Anyway, I don't really care much about priority right now so don't
> > fancy figuring out what exactly it should be (should we have a Thread
> > object too, etc?). Therefore I'd like to keep it as it is but add a
> > FutureWarning so that when we do take the time to sort it out we're
> > not limited by some strange backwards incompatible stuff.
> >
> > Toughts, objections?
> >
>
> Linux "top" shows a priority for each process. Is it just showing
> the same value as PSI? Even if it is an approximation, it is
> presumably the value that users are expecting.
Linux top gives you (priority + (19 - nice)). I'm pretty happy just
giving priority and nice as they are, but maybe it would be good to
document what linux top does.
> I'm not sure how you
> go about calculating a more accurate priority but, if we can,
> perhaps we just expose a new attribute for it when it is ready?
Our priority is pretty accurate, the tests go through a lot of pain to
test out the different schedulers etc and make sure it's correct (when
running as root at least). It's just that it's the instantanious
priority (just like top), while there are many factors interesting:
the scheduler class, base priorities etc. Also the priority of a
process on UNIX is generally the priority of the "representative
thread/LWP" because the threads are the schedulable entities. This
works well for single threaded processes but hides stuff in
multithreaded situations.
I don't think what we provide now is wrong, I just think we don't
provide the whole picture. What made me write this in the first place
was because on Windows I couldn't find the instantanious priority,
only the configurable parameters which the kernel uses to work out the
priority.
Maybe the priority attribute should be left alone and there would only
be more information about priorities in the future. But it's because
I currently haven't got a big enough picture of all the scheduling,
threading and priority information that plays part in this that I
don't know if it would still be meaningful (it would be for a
thread/LWP I think).
Regards
Floris