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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ac3eb2510911181203r1be5c3dajdacec94f196d550c@mail.gmail.com>
Date:	Wed, 18 Nov 2009 21:03:21 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	David Zeuthen <david@...ar.dk>, linux-kernel@...r.kernel.org,
	axboe@...nel.dk, linux-hotplug@...r.kernel.org
Subject: Re: [PATCH] [RFC] Add support for uevents on block device idle 
	changes

On Wed, Nov 18, 2009 at 20:53, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Wed, Nov 18, 2009 at 08:47:37PM +0100, Kay Sievers wrote:
>> On Wed, Nov 18, 2009 at 20:40, Matthew Garrett <mjg@...hat.com> 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.

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.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/