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

Tue Oct 7 08:35:56 UTC 2014

----- Original Message ----- 
From: "Adam McDougall" <mcdouga9 at egr.msu.edu>

> On 10/03/2014 16:34, Steven Hartland wrote:
>> Author: smh
>> Date: Fri Oct  3 20:34:55 2014
>> New Revision: 272483
>> URL: https://svnweb.freebsd.org/changeset/base/272483
>> 
>> Log:
>>   Refactor ZFS ARC reclaim checks and limits
>>   
>>   Remove previously added kmem methods in favour of defines which
>>   allow diff minimisation between upstream code base.
>>   
>>   Rebalance ARC free target to be vm_pageout_wakeup_thresh by default
>>   which eliminates issue where ARC gets minimised instead of balancing
>>   with VM pageout. The restores the target point prior to r270759.
>>   
>>   Bring in missing upstream only changes which move unused code to
>>   further eliminate code differences.
>>   
>>   Add additional DTRACE probe to aid monitoring of ARC behaviour.
>>   
>>   Enable upstream i386 code paths on platforms which don't define
>>   UMA_MD_SMALL_ALLOC.
>>   
>>   Fix mixture of byte an page values in arc_memory_throttle i386 code
>>   path value assignment of available_memory.
>>   
>>   PR: 187594
>>   Review: D702
>>   Reviewed by: avg
>>   MFC after: 1 week
>>   X-MFC-With: r270759 & r270861
>>   Sponsored by: Multiplay
>> 
> 
> Two days ago I started running a r272549 kernel from 11 and tonight I am
> swapping again when I open too many apps but I have plenty of ARC in use:
> 
> last pid:  5471;  load averages:  0.96,  0.53,  0.35    up 1+12:18:43
> 22:53:55
> 82 processes:  1 running, 81 sleeping
> CPU:  2.1% user,  0.0% nice,  2.4% system,  0.0% interrupt, 95.5% idle
> Mem: 1536M Active, 457M Inact, 1667M Wired, 8640K Cache, 85M Free
> ARC: 909M Total, 97M MFU, 556M MRU, 3344K Anon, 19M Header, 234M Other
> Swap: 8192M Total, 19M Used, 8172M Free
> 
>  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU
> COMMAND
> 1135 mcdouga9     97  21    0  1818M   959M select  1 151:35   3.66%
> firefox
> 1128 mcdouga9     41  20    0   867M   384M select  0  19:24   0.00%
> thunderbi
> 5454 mcdouga9      8  20    0  1006M   169M uwait   0   0:03   0.98% chrome
> 5455 mcdouga9      9  20    0  1041M   168M uwait   3   0:03   0.68% chrome
> 5452 mcdouga9     31  20    0   558M   128M select  1   0:03   0.20% chrome
> 5456 mcdouga9      9  20    0  1012M   121M uwait   2   0:03   0.98% chrome
> 5453 mcdouga9      3  20    0   503M   105M kqread  3   0:01   0.10% chrome
> 5457 mcdouga9      8  20    0   962M 86936K uwait   2   0:01   0.20% chrome
> 1088 mcdouga9      4  20    0   268M 23508K select  3   3:01   0.00%
> xfce4-ter
> 1060 mcdouga9      1  20    0   189M 17524K select  2  19:30   0.68% Xorg
> 1085 mcdouga9      3  20    0   254M 16196K select  2   0:24   0.00%
> xfce4-pan
> 1098 mcdouga9      1  20    0   169M 15092K select  0   0:33   0.00%
> wrapper
> 1082 mcdouga9      1  20    0   157M 13784K select  1   0:16   0.00% xfwm4
> 1087 mcdouga9      3  20    0   258M 13308K select  0   0:28   0.00%
> xfdesktop
> 1086 mcdouga9      2  20    0   175M 12120K select  2   0:09   0.00%
> xfsetting
> 
> Earlier today it was over 200M into swap, I noticed churning when I
> opened chromium (forgot to check memory stats first).  I closed
> chromium, ran swapoff and swapon, and used my computer for a little
> while before reporting this, so this is definitely new swap use.

Thats expected behaviour, if said processes are idle. You should however
see ARC reduce at ~ the same time that swapping occurs as prior to r270759.

> I opened a new tab in chromium to my twitter account and now I'm at:
> 
> Mem: 1686M Active, 439M Inact, 1548M Wired, 8640K Cache, 72M Free
> ARC: 793M Total, 94M MFU, 451M MRU, 4148K Anon, 19M Header, 225M Other
> Swap: 8192M Total, 190M Used, 8002M Free, 2% Inuse
> 
> Should I be expected to be tuning variables?  I was previously running a
> patch I applied in June or July to my satisfaction (rarely swapping, ARC
> shrinking when beneficial for a workstation).  Can I help?  Just hoping
> to help arrive at a balanced outcome for 10.1.  Thanks.

Having ARC start reduce before the pagedaemon triggers, as prior to 
commit, could result in ARC pegging back to min.

There's will to be on going work to improve this but my current proposal
is to get this and the previous changes MFC and hopefully into 10.1 so
at least the sysctl is there that people can use.

If for your use you would prefer ARC to reduce instead of idle processes
swap then you could increase vfs.zfs.arc_free_target slightly but be very
aware this is known to cause issues with certain work loads.

The current code includes quite a few new dtrace points which will enable
you to monitor ARC's behaviour, so if you want to investigate its
behaviour this is you best bet. You can find a number of useful dtrace
scripts on the related PR.

    Regards
    Steve