Date: Fri, 28 Jun 2013 08:11:10 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: svn-src-head@freebsd.org, Jeff Roberson <jeff@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r252330 - in head/sys: conf geom kern sys vm Message-ID: <CAJ-VmokXKzGYD%2BHf%2B2iZieYV5-tr46m=TXm7kphC2bC-kArnAg@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1306280032160.95115@desktop> References: <201306280351.r5S3pLAm098083@svn.freebsd.org> <CAJ-VmokRJrdKbZnNEDRfWahsWL-WNReHozV=_t3sw=6OrbcKNQ@mail.gmail.com> <alpine.BSF.2.00.1306280032160.95115@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 June 2013 03:36, Jeff Roberson <jroberson@jroberson.net> wrote: >> Do we really need another allocator / resource manager just for this? >> > > No, however; I have a follow-up patch to replace kmem with this. And then > we will use it for NUMA allocations in the kernel. After that it is likely > that we could replace several other less efficient allocators with this. > Solaris uses it for pids, tids, device unit numbers. etc. We could easily > do the same. The existing allocators have failure modes, big O cost, and > allocation requirements that are not tolerable for use in the vm. This also > has a very nice feature that works with UMA to provide per-cpu caches of > arbitrary number ranges. So it is more scalable as well as providing for > less fragmentation. Sweet. :) Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokXKzGYD%2BHf%2B2iZieYV5-tr46m=TXm7kphC2bC-kArnAg>