Date: Mon, 17 Dec 2012 21:40:07 -0800 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Alan Cox <alc@rice.edu> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: svn commit: r243631 - in head/sys: kern sys Message-ID: <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> In-Reply-To: <50C3AF72.4010902@rice.edu> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <ABB3E29B-91F3-4C25-8FAB-869BBD7459E1@bluezbox.com> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-12-08, at 1:21 PM, Alan Cox <alc@rice.edu> wrote: > On 12/08/2012 14:32, Andre Oppermann wrote: >>>=20 .. skipped .. >>=20 >> The trouble seems to come from NSFBUFS which is (512 + maxusers * 16) >> resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE =3D 27MB. = This >> seem to be pushing it with the smaller ARM kmap layout. >>=20 >> Does it boot and run when you set the tunable kern.ipc.nsfbufs=3D3500? >>=20 >> ARM does have a direct map mode as well which doesn't require the >> allocation >> of sfbufs. I'm not sure which other problems that approach has. >>=20 >=20 >=20 > Only a few (3?) platforms use it. It reduces the size of the user > address space, and translation between physical addresses and direct = map > addresses is not computationally trivial as it is on other > architectures, e.g., amd64, ia64. However, it does try to use large > page mappings. >=20 >=20 >> Hopefully alc@ (added to cc) can answer that and also why the kmap of >> 27MB >> manages to wrench the ARM kernel. >>=20 >=20 >=20 > Arm does not define caps on either the buffer map size (param.h) or = the > kmem map size (vmparam.h). It would probably make sense to copy these > definitions from i386. Adding caps didn't help. I did some digging and found out that although = address range 0xc0000000 .. 0xffffffff is indeed valid for ARM in general actual KVA = space varies for each specific hardware platform. This "real" KVA is defined by = <virtual_avail, virtual_end> pair and ifI use them instead of <VM_MIN_KERNEL_ADDRESS, = VM_MAX_KERNEL_ADDRESS> in init_param2 function my pandaboard successfully boots. Since former = pair is used for defining=20 kernel_map boundaries I believe it should be used for auto tuning as = well.=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?330405A1-312A-45A5-BB86-4969478D8BBD>