On 09/02/2014 14:09, Steven Hartland wrote: > ----- Original Message ----- From: "Alan Cox" <a...@rice.edu> >> On 09/02/2014 12:34, Steven Hartland wrote: >>> ----- Original Message ----- From: "Alan Cox" <a...@rice.edu> >>>> 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? > > In "my" direct experience, I would have to say no, I can't speak for > others. > >>> 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. > > I'm not and don't profess to be an expert in this domain as you > know ;-) So I'm to defer to you guys, Peter would you agree with > this? > >> 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. > > The returns of said functions are uint64_t so I'm not sure where > the overflow would be when working with 2GB values? >
Ah, I didn't see the uint64_t. I only looked at the calculation and assumed vm_offset_t was being used. So, yes, you are safe from overflow. > We seem to be missing some of the following, which doesn't impact > us directly but may affect understanding of the "current" illumos > code as its not in the tree: > https://github.com/illumos/illumos-gate/commit/94dd93aee32d1616436eb51fb7b58094b9a8d3e8 > > > Regards > Steve > > _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
