Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth

From: luca abeni
Date: Tue Jan 26 2016 - 07:52:33 EST

Hi Peter,

On Fri, 15 Jan 2016 09:50:04 +0100
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > >>NOTE: the fraction of CPU time that cannot be reclaimed is
> > >>currently hardcoded as (1 << 20) / 10 -> 90%, but it must be made
> > >>configurable!
> > >
> > >So the alternative is an explicit SCHED_OTHER server which is
> > >configurable.
> > Yes, I have thought about something similar (actually, this is the
> > strategy I implemented in my first CBS/GRUB scheduler. With the
> > "old" 2.4 scheduler, this was easier :).
> > But I think the solution I implemented in this patch is much
> > simpler (it just requires a very simple modification to
> > grub_reclaim()) and is more elegant from the theoretical point of
> > view.
> It is certainly simpler, agreed.
> The trouble is with interfaces. Once we expose them we're stuck with
> them. And from that POV I think an explicit SCHED_OTHER server (or a
> minimum budget for a slack time scheme) makes more sense.
I am trying to work on this.
Which kind of interface is better for this? Would adding something like
be ok?

If this is ok, I'll add these two procfs files, and store
(sched_other_runtime / sched_other_period) << 20 in the runqueue field
which represents the unreclaimable utilization (implementing
hierarchical SCHED_DEADLINE/CFS scheduling right now is too complex for
this patchset... But if the exported interface is ok, it can be
implemented later).

Is this approach acceptable? Or am I misunderstanding your comment?