Date: Tue, 7 Oct 2014 09:35:41 +0100 From: "Steven Hartland" <smh@freebsd.org> To: "Adam McDougall" <mcdouga9@egr.msu.edu>, <svn-src-all@freebsd.org> Subject: Re: svn commit: r272483 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm Message-ID: <B55B217859F3469AB8E919A3168E7BEB@multiplay.co.uk> References: <201410032034.s93KYuUD075578@svn.freebsd.org> <54335819.402@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Adam McDougall" <mcdouga9@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B55B217859F3469AB8E919A3168E7BEB>