On 09/02/2014 12:34, Steven Hartland wrote: > ----- Original Message ----- From: "Alan Cox" <a...@rice.edu> > >> On 09/02/2014 11:01, John Baldwin wrote: >>> On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote: >>>> On Saturday 30 August 2014 02:03:42 Steven Hartland wrote: >>>> I'm very disappointed in the attention to detail and errors in the >>>> commit. I'm almost at the point where I want to ask for the whole >>>> thing to be backed out. >>> I would not be too supportive of that. This PR has been open for a >>> long, long time with many users using patches from it in production >>> loads that were greatly improved by the changes and clamoring on the >>> lists multiple times to get someone to look at it. avg@ contributed >>> quite a bit of time to diagnose this with Karl early on, but other >>> developers aside from Steven did not. It also was not hard to >>> explain to Karl the meaning of 'cache + free' in the bug follow-ups >>> itself (though I believe avg@ had tried this before and it didn't >>> sink in that time for some reason). >>> >>> I know Steven has since committed a fix, but if there are still >>> concerns, I think it would be best to not just revert this entirely >>> but to spend some time fixing the remaining issues. Clearly this >>> issue affects a lot of users and the earlier fixes to pagedaemon >>> were not sufficient to fix their issues alone. >>> >> >> The patch actually makes two completely orthogonal changes at once, and >> one of those changes has no connection to the page daemon. I suspect >> that is why some people have said that their issues were not addressed >> by the page daemon fix. >> >> Prior to this patch, we were limiting the ARC size to 3/4 the kmem >> map/arena/object size on all architectures, including 64-bit, >> uma_small_alloc-enabled architectures where such a limit makes no >> sense. Consequently, some people were complaining, "Why is 1/4 of my >> memory going unused?" > > This is exactly the problem which lead me into investigating the issue. >
Is there any evidence that anything other than eliminating the KVA limit is needed on machines where the page daemon isn't broken? > It should be noted that for i386, as requested by Peter, this limitation > has been re-applied. > Unlike Solaris, we run on a few 32-bit architectures, besides i386, that don't have a direct map or a full 4GB address space for the kernel. So, for FreeBSD, this needs to be more general than just i386. I would suggest using '#ifndef UMA_MD_SMALL_ALLOC' as being the closest thing that we have to what you want here. This check will allow any machine, including 32-bit machines that allocate some kernel memory through a direct map, to opt out of the kmem map/arena/object limit. Finally, the Solaris KVA check is written to avoid the possibility of integer overflow. However, the FreeBSD version is not. For example, suppose that I setup an i386 machine with something approaching a 2GB/2GB user/kernel split, 3 * kmem_size() could overflow. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"