On ke, 2012-05-16 at 12:40 -0700, ext Dmitry Torokhov wrote: > Hi Mika, > > On Tue, May 15, 2012 at 03:46:24PM +0300, Mika Kuoppala wrote: > > If struct evdev_client is added to the already power of two > > buffer allocation and the buffer is large, for multitouch devices, > > the allocation will spill over into the the next page. > > Alloc buffer separately instead of binding it to evdev_client struct > > to avoid multipage kmalloc. > > Not counting the event buffer, size of evdev_client is fairly small > (under 100 bytes?) so I wonder how often this split actually helps (i.e. > buffer and client each are less than page size but combined are more). With normal input devices this never happens as the default event buffer size seem to be 1024 (64 * 16) bytes. But the event buffer size heuristics for multi touch devices this happens very easily. The heuristics will look for ABS_MT_TRACKING_ID min and max values to determine the amount of contacts delivered between two syn events. With 10 contacts and moderate amount of ABS_MT* events between MT_SYNS, you end up easily to more than a page worth of stuff. See driver/input/input.c:input_estimate_events_per_packet() -Mika -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
