lkml.org 
[lkml]   [2008]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Disk shock protection (revisited)
On Tue, 26 Feb 2008, Elias Oltmanns wrote:
> > You don't want, for example, to swap out other apps, swap in the
> > daemon, in order to handle a sudden acceleration.
>
> Quite. But with mlock this particular problem can be handled in user
> space just fine. The only reason I can see right now for putting this

And, as long as there is a way to also invoke it from within the kernel, we
can call it from inside the kernel as well when there is a reason to make
that function available. Full flexibility is easily attainable here and
nothing we should bother about too much.

> logic into the kernel as well is to keep the functionality around even

Some hardware (Apple's?) has the entire APS logic in firmware (and AFAIK
*also* export the accelerometer data for other uses). On those boxes, if
you want to trust the firmware, you just ignore the accelerometer and hook
to an interrupt. When you get the interrupt, you freeze the queue and
unload heads. Adding that to work in-kernel would be trivial.

Adding a suspend-time-only emergency HDAPS in-kernel monitor thread would
also be doable, if we wanted to duplicate that for ThinkPads (I don't really
think it is needed, but...). As long as queue freezing and the required
unload immediate procedure can be called in at *any* time before the disk
device, and its buses and controller are suspended, it would do to implement
whatever we feel it is needed.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


\
 
 \ /
  Last update: 2008-02-26 02:35    [W:0.216 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site