From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 20:11:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA442476; Sat, 5 Apr 2014 20:11:57 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13E079A0; Sat, 5 Apr 2014 20:11:56 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id pn19so3536163lab.34 for ; Sat, 05 Apr 2014 13:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fSDWazIh4p4R7/KwkU7RH7IwZxQrebZphgyLxKUYkNM=; b=SQxavgqHKe37vj/slcLnBK0bak6U34Vsk5GY3srvITZWY2MEP0frF02lA7ILQ+nYL1 qv9nC1S9rs/9/IsFEXMgFTQNtomMVHVWP9/Z4KZ6EEeGRwmtR37SPWfUBXsDEFKB8A9L 3X+NQOgfFih4B0asNYwZ7j328jBkSIMD5mAH6NnFghrxH5+rhVU/ppc5HEFZlhI7qYOO Q8Ho4JtxwgsVt/t2IlnJIzk8lO2hot0QhDnUXI+oyXo6r1EzDw9Xk5C6ePDIb63RWutx 7nOQXCizGZTK7oPimMIYsT6jShZiy/ETedDWxlJKmIcBEEm/kg5+XUEgC//Qtnyr6n0P E2gA== X-Received: by 10.152.42.230 with SMTP id r6mr3015235lal.32.1396728715001; Sat, 05 Apr 2014 13:11:55 -0700 (PDT) Received: from [10.0.1.9] (ip-95-220-108-153.bb.netbynet.ru. [95.220.108.153]) by mx.google.com with ESMTPSA id g8sm11679684laf.0.2014.04.05.13.11.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Apr 2014 13:11:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <5426E303-E35B-4D4A-AB62-3571228A5A2C@gmail.com> Date: Sun, 6 Apr 2014 00:11:51 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DAE3175-FE32-4D17-A386-063DDB6C45F7@gmail.com> References: <201404031102.38598.jhb@freebsd.org> <201404041612.35889.jhb@freebsd.org> <5426E303-E35B-4D4A-AB62-3571228A5A2C@gmail.com> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, =?utf-8?Q?Trond_Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 20:11:57 -0000 On 05 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 1:02, Dmitry Sivachenko = wrote: > On 05 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 0:12, John Baldwin = wrote: >=20 >>=20 >> MADV_WILLNEED is not going to give you what you want. OTOH, if you = haven't >> tried FreeBSD 10 yet, I would suggest trying that. There have been = changes >> to pagedaemon that might make it do a better job of kicking out the = pages >> of the log files automatically. >>=20 >=20 >=20 > I did. My situation became worse after I moved from stable/9 to = stable/10. > My feeling is that stable/10 pushes rarely used mmaped pages out of = RAM more aggressively than stable/9 did. >=20 > For now, the only solution I found is doing msync(MS_INVALIDATE) on = log files after gzipping and after backup via rsync. > This moves corresponding memory pages from Inactive to Free and = prevents system to occupy all free memory with cached log files and to = purge mmaped data out of RAM to accomodate more disk cache. >=20 > What I would love to see is an ability to tell OS not to release = mmaped data unless "really needed" (disk cache is not an excuse). One more observation as it seems to be related. If my program allocates RAM via malloc() rather than mmap(), I see that = VM swaps rarely used parts of malloced data out as disk is being used (more and more memory goes to Inactive with cached files content). This is also different from stable/9 and seems not good. Why to keep = cached content of files forever? (seems there is no timeout for keeping = cached files content in Inactive state). So after few days of uptime = all available RAM is either in Active state with frequently used pages = of running processes or in Inactive state with cached files data. = Rarely used parts of processes memory goes to swap.