From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Date: Wed, 18 Nov 2009 19:53:42 +0000 Subject: Re: [PATCH] [RFC] Add support for uevents on block device idle Message-Id: <20091118195342.GA13627@srcf.ucam.org> List-Id: References: <1258468659-5446-1-git-send-email-mjg@redhat.com> <1258474180.16176.62.camel@localhost.localdomain> <20091117185742.GA19829@srcf.ucam.org> <20091118194053.GB12944@srcf.ucam.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Kay Sievers Cc: David Zeuthen , linux-kernel@vger.kernel.org, axboe@kernel.dk, linux-hotplug@vger.kernel.org On Wed, Nov 18, 2009 at 08:47:37PM +0100, Kay Sievers wrote: > On Wed, Nov 18, 2009 at 20:40, Matthew Garrett wrote: > > On Wed, Nov 18, 2009 at 08:30:07PM +0100, Kay Sievers wrote: > > > >> Wouldn't it be good enough, if we add a file "idle_since" which > >> contains the time of the actual disk idle time, and userspace can > >> schedule a re-examination of that value at the actual end of the idle > >> time it is looking for? > > > > That would require either polling or waking up a userspace application > > on every disk access. Doing it in-kernel involves only a single timer > > wakeup for every active/idle transition. > > How would it? If you look for, like a 60 seconds timeout, and the file > contains 20, you schedule a wakeup in 40 seconds. If the file after > the 40 seconds contains 60, you reached your idle timeout exactly at > that moment, if it's less, then you re-calculate and start from the > beginning. How is that not polling? You'll repeatedly read a file looking for a value that may never appear - imagine the case where you're waiting for 60 seconds of idleness, but the disk always becomes active again after 50. -- Matthew Garrett | mjg59@srcf.ucam.org