Re: [PATCH] optional non-interactive mode for cpu scheduler
From: Con Kolivas
Date: Tue Nov 02 2004 - 09:07:12 EST
Ingo Molnar wrote:
* Con Kolivas <kernel@xxxxxxxxxxx> wrote:
However the non-interactive mode addresses a number of different needs
that seem to have come up. Specifically:
I have had users report great success with such a mode on my own
scheduler in multiple X session setups where very choppy behaviour
occurs in mainline.
since SCHED_CPUBOUND would be inherited across fork(), it should be
rather easy to start an X session with all tasks as SCHED_CPUBOUND.
but i think the above rather points in the direction of some genuine
weakness in the interactivity code (i know, for which the fix is
staircase ;) which would be nice to debug.
Heh I wasnt implying we should move to staircase to fix our problems
(then I'd have nothing special for -ck would I?). I was simply trying to
reproduce that behaviour with a similar mode. As for the choppiness, the
reports were that it would go away if X was run nice+19 which implies no
dynamic priority adjustment was the answer.
Many high performance computing people do not wish interactivity code
modifying their choice of latency/distribution - admittedly this is a
soft one.
well, SCHED_CPUBOUND would solve their needs too, right?
Assuming they wanted to run everything SCHED_CPUBOUND, yes.
Your solution has quite some merit to it :)
I'll look into coding it later this week (thanks for suggesting I do it
btw). This ordeal has left me seriously sleep deprived :P
Since we're considering providing a special cpu policy for high latency
high cpu usage, does that mean we can now talk about other policies like
batch, isochronous etc? And in the medium to long term future, gang and
group?
Regards,
Con
Attachment:
signature.asc
Description: OpenPGP digital signature