Re: [PATCH 7/8] nohz: Evaluate tick dependency once on context switch

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Jun 11, 2015 at 04:46:29PM -0400, Rik van Riel wrote:
> On 06/11/2015 01:36 PM, Frederic Weisbecker wrote:
> > The tick dependency is evaluated on every irq. This is a batch of checks
> > which determine whether it is safe to stop the tick or not. These checks
> > are often split in many details: posix cpu timers, scheduler, sched clock,
> > perf events. Each of which are made of smaller details: posix cpu
> > timer involves checking process wide timers then thread wide timers. Perf
> > involves checking freq events then more per cpu details.
> > 
> > Checking these details every time we update the full dynticks state
> > bring avoidable overhead.
> > 
> > So lets evaluate these dependencies once on context switch. Then the
> > further dependency checks will be performed through a single state check.
> > 
> > This is a first step that can be later optimized by dividing task level
> > dependency, CPU level dependency and global dependency and update
> > each at the right time.
> 
> > +static void tick_nohz_full_update_dependencies(void)
> > +{
> > +	struct tick_sched *ts = this_cpu_ptr(&tick_cpu_sched);
> > +
> > +	if (!posix_cpu_timers_can_stop_tick(current))
> > +		ts->tick_needed |= TICK_NEEDED_POSIX_CPU_TIMER;
> > +
> > +	if (!perf_event_can_stop_tick())
> > +		ts->tick_needed |= TICK_NEEDED_PERF_EVENT;
> > +
> > +	if (!sched_can_stop_tick())
> > +		ts->tick_needed |= TICK_NEEDED_SCHED;
> >  
> 
> I see this getting kicked from task work and from ipi
> context, but does it get kicked on task wakeup, when
> we have a second runnable task on a CPU, but we decide
> not to preempt the currently running task to switch to
> it yet, but we will want to preempt the currently running
> task at a later point in time?

Sure, it's kicked unconditionally as long as the runqueue has more
than one task running. So it includes task wakeup, load balancing, etc...
Everything that calls add_nr_running().

We'll certainly refine that in the long run, perhaps by hooking
on check_preempt_curr() and resched_curr() to minimize the IPIs
and piggyback on the scheduler ipi when possible.