lkml.org 
[lkml]   [2019]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4] sched/core: Preempt current task in favour of bound kthread
On Thu, Dec 12, 2019 at 12:20:01PM +0100, Vincent Guittot wrote:
> On Thu, 12 Dec 2019 at 11:23, Peter Zijlstra <peterz@infradead.org> wrote:

> > Just for giggles, that'd look something like:
> >
> > while (!entity_is_task(se) {
> > cfs_rq = group_cfs_rq(se);
> > se = pick_next_entity(cfs_rq, cfs_rq->curr);
> > }
> > p = task_of(se);
> >
> > if (is_per_cpu_kthread(p))
> > ideal_runtime /= 2;
> >
> > the core-scheduling patch set includes the right primitive for this I
> > think, pick_task_fair().
>
> why not only updating wan_gran() which is the only function which uses
> sysctl_sched_wakeup_granularity ?

I don't see how, it works on se, which need not be a task.

> For per cpu kthread, we could set the gran to sched_min_granularity
> instead of scaling it with thread's priority so per cpu kthread can
> still preempt current ask even if sysctl_sched_wakeup_granularity is
> large

Also, we're not poking at wakeup preemption anymore. That, as explained
by Dave, is not the right thing to do. What we want instead is to make
tick preemption a little more agressive.

And tick based preemption currently purely looks at the leftmost entity
for each runqueue we find while iterating current. IE, it might never
even see the task we tagged with next.

Also, did I say I hates cgroups :-)

\
 
 \ /
  Last update: 2019-12-12 14:14    [W:0.063 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site