Re: USBFS Memory allocation Bug

[Mel Gorman]

On Wed, Mar 10, 2010 at 10:16:09AM -0500, Alan Stern wrote:
> On Wed, 10 Mar 2010, Mel Gorman wrote:
> 
> > On Tue, Mar 09, 2010 at 10:09:57PM +0100, Markus Rechberger wrote:
> > > Hi,
> > > 
> > > I just stumbled around following issue:
> > > 
> > > <SNIP to have one full message>
> > >
> > > [275835.491094] mediasrv: page allocation failure. order:6, mode:0x40d0
> > 
> > This is massive. Why is usbdev_ioctl requiring an order-6 allocation?
> > Does it have the option to fall back to vmalloc() for example?
> 
> We needed to implement an upper limit on the buffer size, and the value
> chosen was sufficient for 8 ms of data.  There is no fallback to
> vmalloc().
> 
> Of course, the mediasrv program could always make multiple smaller
> data submissions instead of a single big one.
> 

Is there any means for the driver to take the large request, break it up
into multiple smaller requests and submit them one at a time?

> > So, it's a high-order allocation but no swap is configured. As the
> > system has a big mix of both anonymous and file memory, it is likely it
> > was unable to find a large enough contiguous range of file-backed memory
> > it could discard. There is pretty much nothing the memory manager could
> > do here. 
> > 
> > FWIW, if swap was configured I'd think there was more the memory manager
> > could have done.
> > 
> > Is usb falling back to vmalloc() or order-0 pages possible?
> 
> No.  It's not possible since the buffer has to be contiguous for DMA
> purposes (this is a requirement of the driver interface).
> 

Regrettably, there is not much the VM can do in this situation. Without
swap, it cannot magic up contiguous memory. If memory compaction gets
merged then it could do more but the risk of failure is still non-zero.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/