From owner-freebsd-stable@FreeBSD.ORG Thu Aug 18 08:16:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4F4106566C for ; Thu, 18 Aug 2011 08:16:53 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 026B38FC08 for ; Thu, 18 Aug 2011 08:16:53 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QtxmT-000Nxd-DC; Thu, 18 Aug 2011 12:16:49 +0400 Message-ID: <4E4CCA6C.8020408@ipfw.ru> Date: Thu, 18 Aug 2011 12:16:44 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20110120 Thunderbird/3.0.11 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4E4143A6.6030307@digsys.bg> <935F8EC2-88E0-45A3-BE8B-7210BE223BC5@mac.com> <4e42a0c0.e2t/9MF98O3HFjb1%perryh@pluto.rain.com> In-Reply-To: <4e42a0c0.e2t/9MF98O3HFjb1%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, daniel@digsys.bg Subject: Re: 32GB limit per swap device? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 08:16:53 -0000 On 10.08.2011 19:16, perryh@pluto.rain.com wrote: > Chuck Swiger wrote: > >> On Aug 9, 2011, at 7:26 AM, Daniel Kalchev wrote: >>> I am trying to set up 64GB partitions for swap for a system that >>> has 64GB of RAM (with the idea to dump kernel core etc). But, on >>> 8-stable as of today I get: >>> >>> WARNING: reducing size to maximum of 67108864 blocks per swap unit >>> >>> Is there workaround for this limitation? Another interesting question: swap pager operates in page blocks (PAGE_SIZE=4k on common arch). Block device size in passed to swaponsomething() in number of _disk_ blocks (e.g. in DEV_BSIZE=512). After that, kernel b-lists (on top of which swap pager is build) maximum objects check is enforced. The (possible) problem is that real object count we will operate on is not the value passed to swaponsomething() since it is calculated in wrong units. we should check b-list limit on (X * DEV_BSIZE512 / PAGE_SIZE) value which is rough (X / 8) so we should be able to address 32*8=256G. The code should look like this: Index: vm/swap_pager.c =================================================================== --- vm/swap_pager.c (revision 223877) +++ vm/swap_pager.c (working copy) @@ -2129,6 +2129,15 @@ swaponsomething(struct vnode *vp, void *id, u_long u_long mblocks; /* + * nblks is in DEV_BSIZE'd chunks, convert to PAGE_SIZE'd chunks. + * First chop nblks off to page-align it, then convert. + * + * sw->sw_nblks is in page-sized chunks now too. + */ + nblks &= ~(ctodb(1) - 1); + nblks = dbtoc(nblks); + + /* * If we go beyond this, we get overflows in the radix * tree bitmap code. */ @@ -2138,14 +2147,6 @@ swaponsomething(struct vnode *vp, void *id, u_long mblocks); nblks = mblocks; } - /* - * nblks is in DEV_BSIZE'd chunks, convert to PAGE_SIZE'd chunks. - * First chop nblks off to page-align it, then convert. - * - * sw->sw_nblks is in page-sized chunks now too. - */ - nblks &= ~(ctodb(1) - 1); - nblks = dbtoc(nblks); sp = malloc(sizeof *sp, M_VMPGDATA, M_WAITOK | M_ZERO); sp->sw_vp = vp; (move pages recalculation before b-list check) Can someone comment on this? >> >> Apparently, the 32GB swapspace limit is per swap area; you can add >> up to 4 swap areas so create two or three 32GB swap partitions. > > Will that enable a 64GB dump? In 8.1, dumpon(8) says: kernel swap pager and dump facility are completely unrelated to each other. The only possible relation is that dumpon rc-script searches first swap device in fstab to notify kernel it should dump on this device. > > The dumpon utility is used to specify a device where the kernel > can save a crash dump in the case of a panic. > ... > For most systems the size of the specified dump device must be > at least the size of physical memory. > ... > The dumpon utility will refuse to enable a dump device which is > smaller than the total amount of physical memory as reported by > the hw.physmem sysctl(8) variable. > > Note the use of the singluar: "a device" and "the specified device". > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >