From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Date: Mon, 23 Nov 2009 19:50:00 +0000 Subject: Re: [PATCH] [RFC] Add support for uevents on block device idle Message-Id: <20091123195000.GK8742@kernel.dk> List-Id: References: <20091118194053.GB12944@srcf.ucam.org> <20091118195342.GA13627@srcf.ucam.org> <20091118200712.GA14026@srcf.ucam.org> <20091122233749.GA9699@ucw.cz> <20091123141754.GE8742@kernel.dk> <20091123142557.GA10084@srcf.ucam.org> <20091123143140.GG8742@kernel.dk> <20091123144238.GA10275@srcf.ucam.org> In-Reply-To: <20091123144238.GA10275@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Matthew Garrett Cc: Pavel Machek , Kay Sievers , David Zeuthen , linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org 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