On Fri, May 18, 2012 at 11:52:54AM +0300, Mika Kuoppala wrote: > 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() That was not my question. I was askig how often it happens that not only input_estimate_events_per_packet() * <packet size> produces large value, but it is less than 4K, but close enough to 4K so that event_client allocated together with the buffer pushes it up over 4K. Thanks. -- Dmitry -- 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
