public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Markus Rechberger <mrechberger@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
Subject: Re: USBFS Memory allocation Bug
Date: Wed, 10 Mar 2010 15:21:25 +0000	[thread overview]
Message-ID: <20100310152125.GN4883@csn.ul.ie> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1003101007410.1516-100000@iolanthe.rowland.org>

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

  reply	other threads:[~2010-03-10 15:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 21:09 USBFS Memory allocation Bug Markus Rechberger
2010-03-09 22:31 ` Alan Stern
2010-03-09 23:32   ` Markus Rechberger
2010-03-10  3:13     ` Alan Stern
2010-03-10  9:33       ` Markus Rechberger
2010-03-10 15:04         ` Alan Stern
2010-03-10 13:57 ` Mel Gorman
2010-03-10 15:16   ` Alan Stern
2010-03-10 15:21     ` Mel Gorman [this message]
2010-03-10 15:49       ` Alan Stern
2010-03-10 15:55         ` Mel Gorman
2010-03-11 16:56           ` Alan Stern
2010-03-14 23:31             ` Andrew Morton
2010-03-15  9:36               ` Mel Gorman
2010-03-15 13:57               ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100310152125.GN4883@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrechberger@gmail.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox