Date: Sat, 08 Dec 2012 21:53:56 +0100 From: Andre Oppermann <andre@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Alfred Perlstein <bright@mu.org>, Alfred Perlstein <alfred@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: svn commit: r243594 - head/sys/netinet Message-ID: <50C3A8E4.3000401@freebsd.org> In-Reply-To: <CAJ-VmomXyB7MgcWfusb7UH-RG%2BDBZaS_LVRiqKoYRcvmU9s%2BbQ@mail.gmail.com> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <AC499CCF-3812-4CA9-929C-05AA4C39F223@mu.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <CAJ-Vmo=okfoDzUSBJ%2B1=iq44EaNw_uOWCOTB-7TVU6%2BdFZeFyA@mail.gmail.com> <50C278B0.3040107@mu.org> <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> <CAJ-VmokjzMxpY0hpxGLq4_yy3tU29JcCTZi8PChn8t7hmbcn8Q@mail.gmail.com> <50C2839B.30709@mu.org> <CAJ-VmomXyB7MgcWfusb7UH-RG%2BDBZaS_LVRiqKoYRcvmU9s%2BbQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08.12.2012 07:33, Adrian Chadd wrote: > I suggest something with some numbers/figures that we can look at and plot. > > Specifically: > > * Let's map out what the inputs are (eg total memory, total VM space) > * Let's map out what the outputs are (eg UMA zone sizing, total mbufs > allowed, etc) > * Let's plot what the current, pre-latest-fiddling-in-current code does; > * Let's plot what you and Andre think it should be, and then we can > see how that works on the RAM constrained platforms; > * Let's have a bit of a chat about it. I think there are a couple of things being mixed up here. One is the ARM problem. This is related to maxusers. See further down. Two is setting limits for a maximal amount of mbufs in the system. This is 50% of real memory or kmem, whichever is lower, by default. Previously certain types where not limited and others were limited based on maxusers. This was overestimating on small memory configs and severely underestimating on large memory configs. Three is setting limits for maxfiles/maxsockets. This is now scaled according to memory as well. Previously it was derived from maxusers as well with the same trouble as in point two. Four is deciding on an optimal hash table size for TCP control blocks. The number of concurrent tcp connections is limited by maxsockets. The point of contention here is with which fraction of the maxsockets value the hash table should end up. The hash table chains entries when a hash bucket collision happens. So no limit there. It all ends up with a time vs. space tradeoff in the hash table. Any of the proposals being discussed is better than what we had before (fixed 512 hash buckets). > Until Oleksandr and Andre figure out exactly why Andre's tweaks have > broken memory allocation on ARM (and until he and I stare at MIPS a > bit more, especially on the RAM constrained AP platforms) we can only > guess what the underlying reasons for his issues are. Oleksandr thinks > "fragmentation", but we just don't know. So that's worth figuring out. There seems to be a problem with sf_buf kmap allocation at least on ARM which results in the kernel becoming unable to allocate a stack for threads and processes. The sf_buf kmap is derived from maxusers which is derived from phypages. Why exactly a kmap allocation of 27MB hoses the whole kernel is not yet understood. > You don't have to wait. There's plenty to do. Heck, I wonder what > platform Oleksandr is using where an ARM board has 1GB of RAM. Maybe > we should get some more of those for people to play with. Your favorite smartphone likely has 512MB-1GB of RAM. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C3A8E4.3000401>