Date: Mon, 18 Aug 2014 12:45:25 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, "Alexander V. Chernikov" <melifaro@freebsd.org>, "Andrey V. Elsukov" <ae@freebsd.org> Subject: Re: superpages for UMA Message-ID: <CAJ-VmokXDtXSqCKo9wNVeqd9yQeZwgvjWqPA4tQnydx%2B0W_Gzg@mail.gmail.com> In-Reply-To: <20140818183925.GP2737@kib.kiev.ua> References: <53F215A9.8010708@FreeBSD.org> <20140818183925.GP2737@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! I dug into this a little bit last year. I saw a lot of time spent just walking TLBs for VM pages when doing a lot of VM page -> network pushing. On the sandy bridge boxes with 1G page entries, the TLB only has 4 entries. The high area of memory isn't 1G aligned, so we don't use 1G pages for all the stuff that's allocated initially. That includes, among other things, all the VM memory that you need. The other thing that crept up was that we don't try to reserve memory in any way - we'll just fragment stuff quickly from the pmap and allocate where we can when we can. So there's currently no attempt to allocate small kernel structures from the same underlying 1G page. That'd be an interesting experiment - allocating VM entries and other small things like rtentry and mbuf UMA entries from one or two 1GB regions of memory. It may make better use of the 1G (or 2M) TLB entries and keep things hot. -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokXDtXSqCKo9wNVeqd9yQeZwgvjWqPA4tQnydx%2B0W_Gzg>