Date: Fri, 3 May 2013 16:47:11 -0400 From: John Baldwin <jhb@freebsd.org> To: src-committers@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r250219 - head/sys/vm Message-ID: <201305031647.11408.jhb@freebsd.org> In-Reply-To: <201305031858.r43IwcAv090426@svn.freebsd.org> References: <201305031858.r43IwcAv090426@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, May 03, 2013 2:58:38 pm John Baldwin wrote: > Author: jhb > Date: Fri May 3 18:58:37 2013 > New Revision: 250219 > URL: http://svnweb.freebsd.org/changeset/base/250219 > > Log: > Fix two bugs in the current NUMA-aware allocation code: > - vm_phys_alloc_freelist_pages() can be called by vm_page_alloc_freelist() > to allocate a page from a specific freelist. In the NUMA case it did not > properly map the public VM_FREELIST_* constants to the correct backing > freelists, nor did it try all NUMA domains for allocations from > VM_FREELIST_DEFAULT. In practice this should never occur as only mips uses this function and the mips code doesn't support multiple domains yet. > - vm_phys_alloc_pages() did not pin the thread and each call to > vm_phys_alloc_freelist_pages() fetched the current domain to choose > which freelist to use. If a thread migrated domains during the loop > in vm_phys_alloc_pages() it could skip one of the freelists. If the > other freelists were out of memory then it is possible that > vm_phys_alloc_pages() would fail to allocate a page even though pages > were available resulting in a panic in vm_page_alloc(). I have seen multiple instances of this panic in production loads however. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305031647.11408.jhb>