From owner-svn-src-all@FreeBSD.ORG Tue Oct 7 03:03:57 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 259FA24F; Tue, 7 Oct 2014 03:03:57 +0000 (UTC) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id D2F7C24A; Tue, 7 Oct 2014 03:03:55 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 52FF648456; Mon, 6 Oct 2014 23:03:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AxdcqBgsTVf; Mon, 6 Oct 2014 23:03:54 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <54335819.402@egr.msu.edu> Date: Mon, 06 Oct 2014 23:03:53 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: svn-src-all@freebsd.org, Steven Hartland Subject: Re: svn commit: r272483 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm References: <201410032034.s93KYuUD075578@svn.freebsd.org> In-Reply-To: <201410032034.s93KYuUD075578@svn.freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 03:03:57 -0000 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. 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.