----- Original Message -----
From: "Adam McDougall" <mcdou...@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
_______________________________________________
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"
