Re: [PATCH 6/7] sched: Clean up preempt_enable_no_resched() abuse

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Nov 21, 2013 at 03:26:17PM +0200, Eliezer Tamir wrote:
> On 21/11/2013 12:10, Peter Zijlstra wrote:
> > On Wed, Nov 20, 2013 at 08:02:54PM +0200, Eliezer Tamir wrote:
> >> IMHO This has been reviewed thoroughly.
> >>
> >> When Ben Hutchings voiced concerns I rewrote the code to use time_after,
> >> so even if you do get switched over to a CPU where the time is random
> >> you will at most poll another full interval.
> >>
> >> Linus asked me to remove this since it makes us use two time values
> >> instead of one. see https://lkml.org/lkml/2013/7/8/345.
> > 
> > I'm not sure I see how this would be true.
> > 
> > So the do_select() code basically does:
> > 
> >   for (;;) {
> > 
> >     /* actual poll loop */
> > 
> >     if (!need_resched()) {
> >       if (!busy_end) {
> > 	busy_end = now() + busypoll;
> > 	continue;
> >       }
> >       if (!((long)(busy_end - now()) < 0))
> > 	continue;
> >     }
> > 
> >     /* go sleep */
> > 
> >   }
> > 
> > So imagine our CPU0 timebase is 1 minute ahead of CPU1 (60e9 vs 0), and we start by:
> > 
> >   busy_end = now() + busypoll; /* CPU0: 60e9 + d */
> > 
> > but then we migrate to CPU1 and do:
> > 
> >   busy_end - now() /* CPU1: 60e9 + d' */
> > 
> > and find we're still a minute out; and in fact we'll keep spinning for
> > that entire minute barring a need_resched().
> 
> not exactly, poll will return if there are any events to report of if
> a signal is pending.

Sure, but lacking any of those, you're now busy waiting for a minute.

> > Surely that's not intended and desired?
> 
> This limit is an extra safety net, because busy polling is expensive,
> we limit the time we are willing to do it.

I just said your limit 'sysctl_net_busy_poll' isn't meaningful in any
way shape or fashion.

> We don't override any limit the user has put on the system call.

You are in fact, note how the normal select @endtime argument is only
set up _after_ you're done polling. So if the syscall had a timeout of 5
seconds, you just blew it by 55.

> A signal or having events to report will also stop the looping.
> So we are mostly capping the resources an _idle_ system will waste
> on busy polling.

Repeat, you're not actually capping anything.

> We want to globally cap the amount of time the system busy polls, on
> average. Nothing catastrophic will happen in the extremely rare occasion
> that we miss.
> 
> The alternative is to use one more int on every poll/select all the
> time, this seems like a bigger cost.

No, 'int' has nothing to do with it, using a semi-sane timesource does.