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

Hi Juri, On Wed, 3 Feb 2016 11:30:19 + Juri Lelli wrote: [...] > > > > Which kind of interface is better for this? Would adding > > > > something like /proc/sys/kernel/sched_other_period_us > > > > /proc/sys/kernel/sched_other_runtime_us > > > > be ok? > > > > > > > > If this is ok, I'll

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

Hi Luca, Peter, On 02/02/16 21:53, Luca Abeni wrote: > On Wed, 27 Jan 2016 15:44:22 +0100 > Peter Zijlstra wrote: > > > On Tue, Jan 26, 2016 at 01:52:19PM +0100, luca abeni wrote: > > > > > > The trouble is with interfaces. Once we expose them we're stuck > > > > with them. And from that POV I

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

Hi Luca, Peter, On 02/02/16 21:53, Luca Abeni wrote: > On Wed, 27 Jan 2016 15:44:22 +0100 > Peter Zijlstra wrote: > > > On Tue, Jan 26, 2016 at 01:52:19PM +0100, luca abeni wrote: > > > > > > The trouble is with interfaces. Once we expose them we're stuck > > > > with

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

Hi Juri, On Wed, 3 Feb 2016 11:30:19 + Juri Lelli wrote: [...] > > > > Which kind of interface is better for this? Would adding > > > > something like /proc/sys/kernel/sched_other_period_us > > > > /proc/sys/kernel/sched_other_runtime_us > > > > be ok? > > > > > > > > If

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

On Wed, 27 Jan 2016 15:44:22 +0100 Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 01:52:19PM +0100, luca abeni wrote: > > > > 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

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

On Wed, 27 Jan 2016 15:44:22 +0100 Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 01:52:19PM +0100, luca abeni wrote: > > > > 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

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

On Tue, Jan 26, 2016 at 01:52:19PM +0100, luca abeni wrote: > > 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

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

On Tue, Jan 26, 2016 at 01:52:19PM +0100, luca abeni wrote: > > 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

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

Hi Peter, On Fri, 15 Jan 2016 09:50:04 +0100 Peter Zijlstra 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

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

Hi Peter, On Fri, 15 Jan 2016 09:50:04 +0100 Peter Zijlstra 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