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

[Alan Cox]

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