From: Mel Gorman <mel@csn.ul.ie>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@suse.de>,
Christoph Lameter <cl@linux-foundation.org>,
Frans Pop <elendil@planet.nl>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Mel Gorman <mel@skynet.ie>
Subject: Re: Memory management woes - order 1 allocation failures
Date: Tue, 2 Mar 2010 17:26:06 +0000 [thread overview]
Message-ID: <20100302172606.GA11355@csn.ul.ie> (raw)
In-Reply-To: <20100301103546.DD86.A69D9226@jp.fujitsu.com>
On Mon, Mar 01, 2010 at 10:42:50AM +0900, KOSAKI Motohiro wrote:
> > AFAICT, even in the worst case, the latter call-site is well below 4K.
> > I have no idea of the tty one.
>
> afaik, tty_buffer_request_room() try to expand its buffer size for efficiency. but Its failure
> doesn't cause any user visible failure. probably we can mark it as NOWARN.
>
> In worst case, maximum tty buffer size is 64K, it can make allocation failure easily.
>
> Alan, Can you please tell us your mention?
>
(Added Greg as current tty maintainer)
For reasons that are not particularly clear to me, tty_buffer_alloc() is
called far more frequently in 2.6.33 than in 2.6.24. I instrumented the
function to print out the size of the buffers allocated, booted under
qemu and would just "cat /bin/ls" to see what buffers were allocated.
2.6.33 allocates loads, including high-order allocations. 2.6.24
appeared to allocate once and keep silent.
While there have been snags recently with respect to high-order
allocation failures in recent kernels, this might be one of the cases
where it's due to subsystems requesting high-order allocations more.
Anyone familiar with tty that might make a guess as to why it allocates
more aggressively?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-03-02 17:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-26 11:32 Memory management woes - order 1 allocation failures Frans Pop
2010-02-26 12:24 ` Frans Pop
2010-02-26 14:01 ` Pekka Enberg
2010-02-26 15:33 ` Frans Pop
2010-02-26 16:43 ` Christoph Lameter
2010-02-26 17:17 ` Pekka Enberg
2010-03-01 1:42 ` KOSAKI Motohiro
2010-03-02 17:26 ` Mel Gorman [this message]
2010-03-02 18:34 ` Alan Cox
2010-03-02 19:11 ` Mel Gorman
2010-03-02 19:29 ` Greg KH
2010-03-02 21:16 ` Mel Gorman
2010-03-02 22:17 ` Alan Cox
2010-03-02 22:29 ` Mel Gorman
2010-03-12 3:32 ` Frans Pop
2010-03-02 23:31 ` KOSAKI Motohiro
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=20100302172606.GA11355@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cl@linux-foundation.org \
--cc=elendil@planet.nl \
--cc=gregkh@suse.de \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@skynet.ie \
--cc=penberg@cs.helsinki.fi \
/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;
as well as URLs for NNTP newsgroup(s).