Re: [Hdaps-devel] [PATCH] hdaps - switch to using input-polldev

[Shem Multinymous]

Hi Dmitry,

On 7/8/07, Dmitry Torokhov <dtor@xxxxxxxxxxxxx> wrote:
> > First, the hdaps driver regularly polls the embedded controller, which
> > in turns regularly polls the hardware. If the two polling rates differ
> > or fluctuate, we lose events.
>
> That was the case with the original driver as well bit instead of
> rearming workqueue it was using rearming timer.

Right. Doesn't the latter result in more regular scheduling?


> > AFAICT, the delayed workqueues used by
> > input-polldev can get very laggy under load. That's very bad for
> > sensitive clients like hdapsd (the hard disk shock protection daemon).
> >
>
> input-polldev uses a separate workqueue, not keventd, and so should not
> suffer from other workqueue users loading keventd. But if entire box
> is under stress then workqueue vs timer context does not matter much -
> your daemon which is in userspace may not get to run in a timely manner
> anyway.

The daemon itself typically runs with a higher priority (and sleeps a
lot so it gets further dumped). More importantly, the daemon depends
not only on the latest measurement, but also on recent measurements
have been obtained from the hardware in a regular fashion and with
reasonably accurate timestamps. And *this* depends solely on the hdaps
driver.


> However I am open to bumping up priority of ipolldevd a little.

Will this result in scheduling tha'ts as reliable as rearming timers
from softirq? I saw claims to the contrary, but it it's true then I
withdraw the first objection.


> > Second, this is incompatible with the much-needed addition of a 2nd
> > input device relying on the same data. The existing hdaps input device
> > does "joystick emulation", i.e., reports values after calibration and
> > fuzzing. Userspace programs that need the raw data, like hdapsd,
> > currently have to poll the sysfs attribute, which is inefficient,
> > lag-prone and induces unnecessary interrupts on tickless sytems. To
> > solve this we'll have to add a 2nd input device to hdaps, for
> > reporting the raw accelerometer data. (Michael Riepe and me are now
> > working on such a patch.) But these two input devices need to share
> > their polling of the underlying EC hardware, and this is impossible
> > using input-polldev.
>
> I am curious why you can't use the current device, since the calibration
> done in hdaps does not alter the scale but merely moves '0' point around.
> And fuzz should only remove small jitters, not rapidly changing data
> that you shoudl get when your box is falling.

Recent versions of the hdapsd daemons do much more than a simple
threshold check: they gather some 2nd-order and decaying averages
statistics to catch subtle abnormal movement (e.g., sliding off a
surface) that's indicative of potential shock. As pointed out in IBM's
HDAPS whitepaper, by the time the box is actually in free fall, it's
too late to start parking the heads. Now, that kind of movement is not
very far from the noise floor, so hdapsd needs all the accuracy it can
get -- hence fuzzing is very disruptive. Calibration is currently
harmless, but I can certainly imagine more advanced hdapsd that uses
heuristics based, e.g., on the absolute orientation of the laptop, so
let's not ruin this data.


> However nothing stops you from generating events for the 2nd input
> device from the same polling function that generates events for the
> first device.

You could one input device open, or the other, or both. How would you
set up input-polldev to handle this?


> > As for the mutex in atomic context issue, isn't it best addressed by
> > making mutex_trylock() do the sensible thing in softirqt?

BTW, I think that's worth fixing in any case.

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