Date: Sun, 21 Jul 2013 02:19:21 -0600 From: Chris Torek <chris.torek@gmail.com> To: alc@freebsd.org Cc: freebsd-current <freebsd-current@freebsd.org>, neel@freebsd.org Subject: Re: expanding past 1 TB on amd64 Message-ID: <CAPx1GvdSmxnXhF3xvhWLscF2H7Vsns6GL7Ve=w_c7iCeAcKPhA@mail.gmail.com> In-Reply-To: <CAJUyCcOxJt5DpZmnmzaV%2B57auntFA37maoic8Wa4_KUZsfoZ-g@mail.gmail.com> References: <201306190832.r5J8WZFE082135@elf.torek.net> <CAJUyCcOxJt5DpZmnmzaV%2B57auntFA37maoic8Wa4_KUZsfoZ-g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(Apologies for delay in reply, family issues) I'd be fine with 4 TB instead of 16; and, at this point, with the latest patches, it's easily tuned. The auto-sizing of the direct map is not affected by sparse space as it keys off Maxmem, which is not actually physical size, but rather "one past last valid physical page". The direct map limit might not need to be "twice kernel virtual size" but on Intel memory-controller systems needs to be "greater than KVM size" due to moving DRAM up past the PCI hole. Unless the restriction that the direct-map area be a power of two size is removed, that winds up meaning "twice". (Removing the restriction seems easy enough=97instead of "pa | highbits" to obtain VA and "va &~ highbits" to obtain PA, just use "phys + offset" and "virt - offset". I didn't see a reason to bother with the effort, though.) Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPx1GvdSmxnXhF3xvhWLscF2H7Vsns6GL7Ve=w_c7iCeAcKPhA>