On Thu, Apr 26, 2012 at 12:35:46PM -0700, Havard Skinnemoen wrote: > (resending because I sent HTML mail by mistake, so it got rejected by > vger. Sorry!) > > On Thu, Apr 26, 2012 at 11:21 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Apr 26, 2012 at 11:16:00AM -0700, Havard Skinnemoen wrote: > >> Everytime a HID device is opened, a new hiddev_list is allocated with > >> kzalloc. This requires 64KB of physically contiguous memory, which could > >> easily push a heavily loaded system over the edge. > > > > Really? 64Kb is a "trigger"? What type of systems are we talking about > > here that this happens on? > > It doesn't happen often, but a system which is already under heavy > memory pressure sometimes gets pushed over the edge by an order-4 > allocation. > > (and "over the edge" can take on many forms, from occasional page > allocation failures through frantic reclaim slowing down the whole > system to OOMs. While hiddev is certainly not responsible for all of > those problems, it seemed like an easy thing to fix and therefore a > good place to start.) > > I've also seen a couple of reports in the wild which look related: > > http://ubuntuforums.org/showthread.php?t=1677131 > http://answerpot.com/showthread.php?1685298-page+allocation+failures Ok, those look valid, thanks. > > And who is opening lots of HID devices? This should only happen once at > > startup, and usually not again, unless a new device is added to the > > system, right? > > The memory is allocated every time the device is opened, and things > like apcupsd seem to do that a lot. > > >> Allocating the same amount of memory with vmalloc shouldn't be nearly as > >> demanding, so let's do that instead. The memory isn't used for DMA and > >> doesn't look particularly performance sensitive, so this should be safe. > > > > Have you found that this patch solves the issue you are having? I'm > > sure that some other 64Kb allocation will then cause a problem, right? > > Well, yes, there are other culprits too, but we need to start > somewhere, and fixing one allocation will hopefully make the problem > happen less often. Well, it will push it off to some other part of the kernel in the end, right? The real memory-pressure problem should probably be reported and fixed in the mm core, if it hasn't already (lots of work has happened in that area since 2.6.32 and 2.6.34 in those reports came out). I'll defer to Jiri, but really, this is just papering over the true problem, which isn't that nice. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
