On 6/3/19 6:37 AM, Peter Zijlstra wrote: > On Fri, May 31, 2019 at 03:12:13PM -0600, Jens Axboe wrote: >> On 5/30/19 2:03 AM, Peter Zijlstra wrote: > >>> What is the purpose of that patch ?! The Changelog doesn't mention any >>> benefit or performance gain. So why not revert that? >> >> Yeah that is actually pretty weak. There are substantial performance >> gains for small IOs using this trick, the changelog should have >> included those. I guess that was left on the list... > > OK. I've looked at the try_to_wake_up() path for these exact > conditions and we're certainly sub-optimal there, and I think we can put > much of this special case in there. Please see below. > >> I know it's not super kosher, your patch, but I don't think it's that >> bad hidden in a generic helper. > > How about the thing that Oleg proposed? That is, not set a waiter when > we know the loop is polling? That would avoid the need for this > alltogether, it would also avoid any set_current_state() on the wait > side of things. > > Anyway, Oleg, do you see anything blatantly buggered with this patch? > > (the stats were already dodgy for rq-stats, this patch makes them dodgy > for task-stats too) Tested this patch, looks good to me. Made the trace change to make it compile, and also moved the cpu = task_cpu() assignment earlier to avoid uninitialized use of that variable. How about the following plan - if folks are happy with this sched patch, we can queue it up for 5.3. Once that is in, I'll kill the block change that special cases the polled task wakeup. For 5.2, we go with Oleg's patch for the swap case. -- Jens Axboe
