svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

[Steven Hartland]

----- Original Message ----- 
From: "Alan Cox" <alc at rice.edu>
> On 09/02/2014 12:34, Steven Hartland wrote:
>> ----- Original Message ----- From: "Alan Cox" <alc at 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?

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