On Mon, Nov 23 2009, Matthew Garrett wrote: > On Mon, Nov 23, 2009 at 03:31:40PM +0100, Jens Axboe wrote: > > > Well, take a look at laptop mode. A timer per-io is probably > > unavoidable, but doing it at IO completion could mean a big decrease in > > timer activity as opposed to doing it for each incoming IO. And since > > you are looking at when the disk is idle, it makes a lot more sense to > > me to do that when the we complete a request (and have no further > > pending IO) rather than on incoming IO. > > Right. The current implementation I have does a del_timer() at > submission (which should be moved to post-merge) - that should be cheap > in the common case of a new command being submitted when there's already > commands outstanding. There's then a mod_timer() at completion time. > That's still a certain amount of expense, but it should be less. > > > Your biggest performance issue here is going to be sync IO, since the > > disk will go idle very briefly before being kicked into action again. > > Ok, I'll try to benchmark that. > > The alternative (polling) method would be something much like Kay > suggested - either add an extra field to stat or an extra sysfs file, > then invalidate that on submission and set to jiffies on completion. > It's not ideal from a wakeups perspective, but it's pretty low impact on > the kernel side. If the polling works out, then yes that approach is certainly a lot better from a performance impact pov. What kind of time intervals are you targetting? -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
