Re: [PATCH v4] sched/core: Preempt current task in favour of bound kthread

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 12, 2019 at 12:20:01PM +0100, Vincent Guittot wrote:
> On Thu, 12 Dec 2019 at 11:23, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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 :-)



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux