Re: [PATCH] optional non-interactive mode for cpu scheduler

[Con Kolivas]

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