On Mon, Jun 24 2013, Steven Rostedt wrote: > On Mon, Jun 24, 2013 at 09:17:18AM +0200, Jens Axboe wrote: > > On Sun, Jun 23 2013, Linus Torvalds wrote: > > > > > > You could try to do that either *in* the idle thread (which would take > > > the context switch overhead - maybe negating some of the advantages), > > > or alternatively hook into the scheduler idle logic before actually > > > doing the switch. > > > > It can't happen in the idle thread. If you need to take the context > > switch, then you've negated pretty much all of the gain of the polled > > approach. > > What about hooking into the idle_balance code? That happens if we are > about to go to idle but before the full schedule switch to the idle > task. > > > In __schedule(void): > > if (unlikely(!rq->nr_running)) > idle_balance(cpu, rq); If you can avoid the switch (sleep/wakeup), then that's what matters. If you end up sleeping, you've lost that latency game and polling is mostly useful in the blk_iopoll designed fashion for high iops scenarios. Besides, you need the task + page context to be able to find out what to poll for (and when to stop). -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
