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 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.

It should be noted that for i386, as requested by Peter, this limitation
has been re-applied.

    Regards
    Steve