Date: Thu, 21 Sep 2006 11:45:28 -0400 From: Martin Cracauer <cracauer@cons.org> To: Danny Braniss <danny@cs.huji.ac.il> Cc: Christos Zoulas <christos@zoulas.com>, freebsd-amd64@freebsd.org, am-utils@fsl.cs.sunysb.edu Subject: Re: mlockall() failes on amd64 Message-ID: <20060921154528.GA51442@cons.org> In-Reply-To: <E1GOcqt-000G17-L9@cs1.cs.huji.ac.il> References: <E1GOcqt-000G17-L9@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
Danny Braniss wrote on Sat, Sep 16, 2006 at 07:17:11PM +0300: > > On Sep 16, 2:55pm, danny@cs.huji.ac.il (Danny Braniss) wrote: > > -- Subject: mlockall() failes on amd64 > > > > | with am-utils 6.1.5, on a amd64 6.1-STABLE kernel i see: > > | Couldn't lock process pages in memory using mlockall() > > | while it's ok on a i386: > > | Locked process pages in memory > > | > > > > We should really fix amd to print the errno string when system calls > > fail; now we can only scratch our heads. > > > > christos > sorry, here is the full message: > Couldn't lock process pages in memory using mlockall(): Resource temporarily > unavailable > > or error = EAGAIN (ED :-) I didn't read the code, but one thing to check is that there is enough paging space to move all dirty/cow/anonymous pages from all other processes to to make room for your current process (including file-backed pages which might not yet be in). I imagine that on AMD64 some programs might overcommit much more since it's "free" (you won't run out of virtual address space). But mlockall will choke on it. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060921154528.GA51442>