From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 20:24:47 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 408ADF3B; Thu, 13 Feb 2014 20:24:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12B101E4C; Thu, 13 Feb 2014 20:24:47 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 28D38B9D8; Thu, 13 Feb 2014 15:24:46 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: Use of contiguous physical memory in cxgbe driver Date: Thu, 13 Feb 2014 15:16:54 -0500 Message-ID: <6154054.5G06XIekg6@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402121446.19278.jhb@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Feb 2014 15:24:46 -0500 (EST) Cc: FreeBSD Net , Garrett Wollman , Navdeep Parhar , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:24:47 -0000 On Wednesday, February 12, 2014 03:36:38 PM Adrian Chadd wrote: > On 12 February 2014 11:46, John Baldwin wrote: > > Is this because UMA keeps lots of mbufs cached in your workload? The > > physmem buddy allocator certainly seeks to minimize fragmentation. > > However, it can't go yank memory out of UMA caches to do so. > > I'll ask you on irc, but where's that happening? My read of the code > is that once it grabs a larger page and fragments it, it's lost. It seeks to use the smallest size possible however. It is true that we don't attempt to move a busy page elsewhere to free up memory (e.g. if you had a 2MB free chunk with one busy 4k page in the middle), but we can't really do that safely. Given the existence of the direct map, we can't relocate a page and be sure that we have also relocated all possible pointers to it. -- John Baldwin