On Monday 09 July 2007 00:31, Shem Multinymous wrote: > Hi Dmitry, > > On 7/8/07, Dmitry Torokhov <[EMAIL PROTECTED]> 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? >
Probably. > > > > 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. > Every input event carries a timestamp so even if there are irregularities in taking the samples you should be able to account for it. > > > 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. Probably not. But I still think that if system is so busy that it can't get aroung to schedule one of workqueues it will not be able to part the driver fast enough anyway. > > > > 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. If hdaps is the main consumer for the data it may be a good idea to just remove the fuzz setting from input device. I don't have the hardware, how bad is it without fuzz? > > > > 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? > Have 2nd input device's ->open() method call input_open_device() for the first one. > > > > 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 > -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
