From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 14:50:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532971065696 for ; Thu, 10 Dec 2009 14:50:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id D444A8FC14 for ; Thu, 10 Dec 2009 14:50:57 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id nBAEothU031301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Dec 2009 15:50:55 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id nBAEoqCt000391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 15:50:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id nBAEoqJI028612; Thu, 10 Dec 2009 15:50:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id nBAEoq4N028611; Thu, 10 Dec 2009 15:50:52 +0100 (CET) (envelope-from ticso) Date: Thu, 10 Dec 2009 15:50:52 +0100 From: Bernd Walter To: John Baldwin Message-ID: <20091210145052.GX20668@cicely7.cicely.de> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912090907.33433.jhb@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.029, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 14:50:58 -0000 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. 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? I obviously don't have enough clue about this to understand those details. Hope that someone can enlighten me. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.