Re: [PATCH] [RFC] Add support for uevents on block device idle changes

Kay Sievers
2009-11-18T21:29:38Z

On Wed, Nov 18, 2009 at 22:06, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Nov 18, 2009 at 21:07, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> On Wed, Nov 18, 2009 at 09:03:21PM +0100, Kay Sievers wrote:
>>
>>> Sure, but what's wrong with reading that file every 50 seconds? Almost
>>> all boxes poll for media changes of optical drives and usb card
>>> readers anyway, so it's not that we are not doing stuff like this
>>> already.
>>
>> We poll for media because there's no event-based way of avoiding it - in
>> this case there is.
>
> That's true, but I think there is a significant difference between
> polling every one or two seconds for media changes, and usually one or
> two minutes for a disk idle. It's not that we poll in a rather hight
> frequency, in an arbitrary interval, and check if some condition is
> met.
>
> I still don't think that we should add new event interfaces which are
> single-subscriber only, and use global values for a specific user.
> What if there will be another independent user for this, which might
> want a different timeout? They fight over the trigger value to set in
> sysfs?
>
> From my perspective, the once-at-timeout wakeup is more acceptable
> than an in-kernel policy setting for a single-subscriber event
> interface.

I guess, the "idle_since" file could be made poll()able, and throw an
event when the idle time is re-set to 0, so the value checking needs
only to happen as long we wait for the disk to become idle. As long as
it's busy anyway, the rare wakeups should not matter much. :)

Kay