Date: Thu, 10 Dec 2009 11:13:56 -0500 From: John Baldwin <jhb@freebsd.org> To: ticso@cicely.de Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt <linda.messerschmidt@gmail.com> Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE Message-ID: <200912101113.56570.jhb@freebsd.org> In-Reply-To: <20091210145052.GX20668@cicely7.cicely.de> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 10 December 2009 9:50:52 am Bernd Walter wrote: > On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote: > > On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote: > > > It's not clear to me if this might be a problem with the superpages > > > implementation, or if squid does something particularly horrible to > > > its memory when it forks to cause this, but I wanted to ask about it > > > on the list in case somebody who understands it better might know > > > whats going on. :-) > > > > I talked with Alan Cox some about this off-list and there is a case that can > > cause this behavior if the parent squid process takes write faults on a > > superpage before the child process has called exec() then it can result in > > superpages being fragmented and never reassembled. Using vfork() should > > prevent this from happening. It is a known issue, but it will probably be > > some time before it is addressed. There is lower hanging fruit in other areas > > in the VM that will probably be worked on first. > > For me the whole threads puzzles me. > Especially because vfork is often called a solution. > > Scenario A > Parent with super page > fork/exec > This problem can happen because there is a race. > The parent now has it's super pages fragmented permanently!? > the child throws away his pages because of the exec!? > > Scenario B > Parent with super page > vfork/exec > This problem won't happen because the child has no pseudo copy of the > parents memory and then starts with a completely new map. Actually, the fact that vfork() doesn't let the parent execute until the child has called exec() also closes the race, as it were, and that was the primary reason in my mind for saying that vfork() would prevent it. > Scenario C > Parent with super page > fork/ no exec > The problem can happen because the child shares the same memory over > it's complete lifetime. > The parent can get it's super pages fragmented over time. > > I don't see a use case for scenario A, because vfork is there since > over 16 years. > I use fork myself, because it is easier sometimes, but people writing > big programms such as squid should know better. > If squid doesn't use vfork they likely have a reason. > With scenario C I don't see how vfork can help, since this is not a legal > case for vfork. > I use quid myself, but don't know how it handles it's childs. > But isn't the whole story about such slave childs that they share memory > with the master? - How can vfork be solution for this case? > How can fragmentation of super pages be avoided at all? In Linda's case it was a fork to run a log rotation binary, so it was A). For C) I think you would want to map the pages MAP_SHARED (or use minherit(2) with INHERIT_SHARE) in which case they would not be COW'd on fork() and you would keep the superpages. Assuming that you explicitly want to share the memory with your child processes you already have to do this to really do sharing anyway. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912101113.56570.jhb>