On Mon, 08 Jul 2013 22:46:04 +0300 Eliezer Tamir <eliezer.ta...@linux.intel.com> wrote:
> On 08/07/2013 22:37, Linus Torvalds wrote: > > On Mon, Jul 8, 2013 at 10:14 AM, Eliezer Tamir > > <eliezer.ta...@linux.intel.com> wrote: > >> > >> I think there is no way for the compiler to know the value of > >> can_busy_loop at compile time. It depends on the replies we get > >> from polling the sockets. ll_flag was there to make sure the compiler > >> will know when things are defined out. > > > > No, my point was that we want to handle the easily seen register test > > first, and not even have to load current(). > > > > The compiler may end up scheduling the code to load current anyway, > > but the way you wrote it it's pretty much guaranteed that it will do > > it. > > I see. OK. > > > In fact, I'd argue for initializing start_time to zero, and have the > > "have we timed out" logic load it only if necessary, rather than > > initializing it based on whether POLL_BUSY_WAIT was set or not. > > Because one common case - even with POLL_BUSY_WAIT - is that we go > > through the loop exactly once, and the data exists on the very first > > try. And that is in fact the case we want to optimize and not do any > > extra work for at all. > > > > So I would actually argue that the whole timeout code might as well be > > something like > > > > unsigned long start_time = 0; > > ... > > if (want_busy_poll && !need_resched()) { > > unsigned long now = busy_poll_sched_clock(); > > if (!start_time) { > > start_time = now + sysctl.busypoll; > > continue; > > } > > if (time_before(start_time, now)) > > continue; > > } > > > Since this code is in hot path, and a special case, looks like a good candidate for static branch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/