Date: Fri, 19 Oct 2007 23:31:55 +0400 From: Ruslan Ermilov <ru@freebsd.org> To: Christopher Chen <muffaleta@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: rpc.statd--256M okay, but 1G? Message-ID: <20071019193155.GA40442@team.vega.ru> In-Reply-To: <7bc80d500710181207pe161b81j3131d370bbbbc631@mail.gmail.com> References: <7bc80d500710181207pe161b81j3131d370bbbbc631@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 18, 2007 at 12:07:02PM -0700, Christopher Chen wrote: > Is there a simple and easy reason why rpc.statd would mmap 1G? I've > read the FAQ and understand why it would allocate 256M, but this one > shows 1G--file.c in /usr/src/usr.sbin/rpc.statd is still set to > allocate 256M, btw. > > This is a 6.2 machine on i386, with 4G RAM, but PAE is not enabled. > That's what I would assume, that if PAE was enabled, it may change the > characteristics of that mmap (but even then, the address space of each > process would be the same...) > > The machine is a nfs client, has no exports, and has two mounts. > > Any quick thoughts? > It has been fixed in RELENG_6 in rev. 1.12.8.2 of statd.c: : revision 1.12.8.2 : date: 2007/08/12 01:46:19; author: truckman; state: Exp; lines: +1 -1 : MFC statd.c 1.15 - : The call to init_file() needs to be moved outside the loop in statd.c, : otherwise mmap() gets called multiple times, which eventually fails due : to address space exhaustion on i386. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071019193155.GA40442>