All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Zdenek Kabelac <zkabelac@redhat.com>
Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
	Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>,
	agk@redhat.com
Subject: Re: [PATCH] Don't mlock guardpage if the stack is growing up
Date: Mon, 9 May 2011 16:45:11 -0600	[thread overview]
Message-ID: <20110509224511.GC15227@parisc-linux.org> (raw)
In-Reply-To: <4DC7D37F.9040308@redhat.com>

On Mon, May 09, 2011 at 01:43:59PM +0200, Zdenek Kabelac wrote:
> > Why it doesn't use mlockall()? Because glibc maps all locales to the 
> > process. Glibc packs all locales to a 100MB file and maps that file to 
> > every process. Even if the process uses just one locale, glibc maps all.
> > 
> > So, when LVM used mlockall, it consumed >100MB memory and it caused 
> > out-of-memory problems in system installers.
> > 
> > So, alternate way of locking was added to LVM --- read all maps and lock 
> > them, except for the glibc locale file.
> > 
> > The real fix would be to fix glibc not to map 100MB to every process.
> 
> I should add here probably few words.
> 
> Glibc knows few more ways around - so it could work only with one locale file
> per language, or even without using mmap and allocating them in memory.
> Depends on the distribution usually - Fedora decided to combine all locales
> into one huge file (>100MB) - Ubuntu/Debian mmaps each locales individually
> (usually ~MB)

Sounds to me like glibc should introduce an mlockmost() call that does all
the work for you ...

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  parent reply	other threads:[~2011-05-09 22:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-08 18:55 [PATCH] Don't mlock guardpage if the stack is growing up Mikulas Patocka
2011-05-08 20:12 ` Hugh Dickins
2011-05-09 11:12   ` Mikulas Patocka
2011-05-09 15:57     ` Linus Torvalds
2011-05-09 22:07       ` Linus Torvalds
2011-05-09 22:07         ` Linus Torvalds
2011-05-09 22:19         ` James Bottomley
2011-05-09 22:19           ` James Bottomley
2011-05-09 22:31           ` Linus Torvalds
2011-05-09 22:31             ` Linus Torvalds
2011-05-09 22:53             ` Tony Luck
2011-05-09 22:53               ` Tony Luck
2011-05-09 22:58               ` Linus Torvalds
2011-05-09 22:58                 ` Linus Torvalds
2011-05-09 23:08                 ` Tony Luck
2011-05-09 23:08                   ` Tony Luck
2011-05-09 23:17                   ` Linus Torvalds
2011-05-09 23:17                     ` Linus Torvalds
2011-05-09 23:25                     ` Linus Torvalds
2011-05-09 23:25                       ` Linus Torvalds
2011-05-10  4:12                       ` James Bottomley
2011-05-10  4:12                         ` James Bottomley
2011-05-09 22:26         ` Mikulas Patocka
2011-05-09 22:26           ` Mikulas Patocka
2011-05-15 22:18           ` Mikulas Patocka
2011-05-15 22:18             ` Mikulas Patocka
2011-05-08 21:47 ` Linus Torvalds
2011-05-08 21:47   ` Linus Torvalds
2011-05-09 11:01   ` Mikulas Patocka
2011-05-09 11:43     ` Zdenek Kabelac
2011-05-09 21:08       ` Alasdair G Kergon
2011-05-09 21:08         ` Alasdair G Kergon
2011-05-09 22:45       ` Matthew Wilcox [this message]
2011-05-09 22:56         ` Linus Torvalds
2011-05-10 22:57           ` Alasdair G Kergon
2011-05-10 22:57             ` Alasdair G Kergon
2011-05-11  8:42             ` Milan Broz
2011-05-11  8:42             ` Milan Broz
2011-05-12  2:12               ` Linus Torvalds
2011-05-12  9:06                 ` Zdenek Kabelac

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=20110509224511.GC15227@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=agk@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=mikulas@artax.karlin.mff.cuni.cz \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=zkabelac@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.