Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option

[Peter Zijlstra]

On Thu, Jul 27, 2017 at 06:08:16AM -0700, Paul E. McKenney wrote:

> > No. Its called wakeup latency :-) Your SCHED_OTHER task will not get to
> > insta-run all the time. If there are other tasks already running, we'll
> > not IPI unless it should preempt.
> > 
> > If its idle, nobody cares..
> 
> So it does IPI immediately sometimes.
> 
> > > Does this auto-throttling also apply if the user is running a CPU-bound
> > > SCHED_BATCH or SCHED_IDLE task on each CPU, and periodically waking up
> > > one of a large group of SCHED_OTHER tasks, where the SCHED_OTHER tasks
> > > immediately sleep upon being awakened?
> > 
> > SCHED_BATCH is even more likely to suffer wakeup latency since it will
> > never preempt anything.
> 
> Ahem.  In this scenario, SCHED_BATCH is already running on a the CPU in
> question, and a SCHED_OTHER task is awakened from some other CPU.
> 
> Do we IPI in that case.

So I'm a bit confused as to where you're trying to go with this.

I'm saying that if there are other users of our CPU, we can't
significantly disturb them with IPIs.

Yes, we'll sometimes IPI in order to do a preemption on wakeup. But we
cannot always win that. There is no wakeup triggered starvation case.

If you create a thread per CPU and have them insta sleep after wakeup,
and then keep prodding them to wakeup. They will disturb things less
than if they were while(1); loops.

If the machine is otherwise idle, nobody cares.

If there are other tasks on the system, the IPI rate is limited to the
wakeup latency of you tasks.


And any of this is limited to the CPUs we're allowed to run in the first
place.


So yes, the occasional IPI happens, but if there's other tasks, we can't
disturb them more than we could with while(1); tasks.


OTOH, something like:

	while(1)
		synchronize_sched_expedited();

as per your proposed patch, will spray IPIs to all CPUs and at high
rates.