From owner-freebsd-hackers@freebsd.org Tue Apr 26 02:31:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9E39B0D247 for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B119A1BFF for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: by mailman.ysv.freebsd.org (Postfix) id B0252B0D245; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFCCCB0D244 for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83CBD1BFD for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: by mail-pa0-x22d.google.com with SMTP id zm5so830153pac.0 for ; Mon, 25 Apr 2016 19:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonov-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=6LmaRlNY00yLIRo6bgAvV+qfwksw35keCVcBTYVRpTU=; b=iHQJaxk2vFcP5cwduxbuA4DQF6Du8YjL/rLGfnCvIVCy7pP+eo+QQ2n1JectLvwFfc VT2Bx/pZJnduECA0jXaylqgLzKKWNTUHckRHWGMkUq/zM+kDipb/ifexkN4ryO+ppDBW SgTETebWGpHPoijSqxoawC7f8Q+OmQ/eVw7uRiRF+Ou0fzlVZFfqhz8TCn9/N8RtIJ3L lFU+08yjaFr66Zh5dibqqRw2PBCY2Zz68nDlf6FtQ2uu+Z6cR57Gx5s95km/sUK9kEpM JevHHCfAhX/IjT0AJWvOJzMHMPGdHT91w/M/NhMzByI8D5zb6oO0PVAE0WwwkDCmj2Ag uX1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=6LmaRlNY00yLIRo6bgAvV+qfwksw35keCVcBTYVRpTU=; b=EIx9M0mUPQAiVMnQlqstIFFDPvf/2NzhidRoguXcn13EJDrWw3MBvgY8twGwLC/rk8 D3Y8aaf1O+U5z/biCmf5P7nV1LkRPYqvvVw8Q20NFe4ndPI3FMDm7ioHGeM3mWYLDTB+ h6uwATriVA3Letbd/NE9Vz3ARn1/vwgrKnCJpHVNJyXXqHdBLsQR5WR+M0/JzdvpGR6w 1fRZUHxUi4rcI55RAB+LyKBkUlmR6pJkRFLTMNMn6MLkHrGStxunCZZn3PrKEt9OKpdR 20KmG4ks15v9IRTO1JzWa9a8w450w+erYZmAgngr9ntcmBb131qxFtIQU0GO0P+6Ujsz DqPw== X-Gm-Message-State: AOPr4FXLQwKsv5Lq0ONAH4AWciMQ253R8ygt3dznrDTYy3KgOPkX9JuzmWBgsPB7vkyLjQ== X-Received: by 10.66.74.138 with SMTP id t10mr175699pav.22.1461637918573; Mon, 25 Apr 2016 19:31:58 -0700 (PDT) Received: from zont-osx-2.local (c-69-181-251-166.hsd1.ca.comcast.net. [69.181.251.166]) by smtp.googlemail.com with ESMTPSA id t1sm33308704paa.17.2016.04.25.19.31.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 19:31:57 -0700 (PDT) Sender: Andrey Zonov Subject: Re: Strange memory management with mmap() To: Dmitry Sivachenko , hackers@freebsd.org References: <3434ED75-7994-4E9E-9B06-FACCD7DC90FF@gmail.com> <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> From: Andrey Zonov Message-ID: <571ED318.1030402@FreeBSD.org> Date: Mon, 25 Apr 2016 19:31:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 02:32:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0 Content-Type: multipart/mixed; boundary="H0tpX72hev2JCjPQh7huOmFm9x5V1gTBo" From: Andrey Zonov To: Dmitry Sivachenko , hackers@freebsd.org Message-ID: <571ED318.1030402@FreeBSD.org> Subject: Re: Strange memory management with mmap() References: <3434ED75-7994-4E9E-9B06-FACCD7DC90FF@gmail.com> <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> In-Reply-To: <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> --H0tpX72hev2JCjPQh7huOmFm9x5V1gTBo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/22/15 5:47 AM, Dmitry Sivachenko wrote: >=20 >> On 16 =D0=B8=D1=8E=D0=BB=D1=8F 2015 =D0=B3., at 21:19, Dmitry Sivachen= ko wrote: >> >>> >>> On 16 =D0=B8=D1=8E=D0=BB=D1=8F 2015 =D0=B3., at 18:42, Dmitry Sivache= nko wrote: >>> >>> Hello! >>> >>> I am using FreeBSD-10-stable and writing a program that uses large da= ta file via mmap() in read only mode. >>> To be specific, I have 256GB RAM machine and typical size of data fil= e is ~160GB (more than 1/2 of RAM and less that the whole RAM). >>> There is no other programs running during the test. >>> >>> Consider the following use case: I have two files on disk. I mmap() = the first one and prefetch data to RAM (touch every page of the file). >>> After that I expect all data to be cached in RAM and subsequent acces= s will be fast. >>> >>> Next I do munmap() on the first file, mmap() the second one and do th= e same test: prefetch data and expect it to be cached in RAM (and some of= the pages belonging to the first file to be purged out, because size_of(= file1)+size_of(file2) > size_of(RAM). >>> >>> Please find my test program attached. >>> >>> I run the program with 2 files provided via command line (both about = 160GB). >>> What I observe in real is: >>> -- before I run the program all RAM is in FREE state as reported by t= op(1). >>> -- after first prefetch() of the first file, all it's data goes to "C= ache" state, RES column of the process remains the same (small) >>> -- second prefetch() works fast as expected, memory goes from Cache t= o Active state, RES column of the process grows up to match file size (SI= ZE=3D=3DRES now) >>> -- now first prefetch() for second file starts: the remaining Free me= mory goes to Cache state, Active size still equals to first file size. >>> -- second prefetch() for second file works as slow as first one, like= if nothing was cached in memory during the first prefetch() run, RES col= umn does not change. >>> >>> >>> Here is the output: >>> % /tmp/a.out file1.dat file2.dat >>> file1.dat... First prefault time: 1235.747351 seconds >>> Second prefault time: 74.893323 seconds >>> Ok. >>> file2.dat... First prefault time: 1316.405527 seconds >>> Second prefault time: 1311.491842 seconds >>> Ok. >>> >> >> >=20 >=20 > I tried the same test program on Linux machine with similar hardware. = It behaves like expected (second prefetch works very fast): >=20 > file1.dat... First prefault time: 2664.621088 seconds > Second prefault time: 1.969283 seconds > Ok. > file2.dat... First prefault time: 2917.009003 seconds > Second prefault time: 34.128762 seconds > Ok. >=20 "Cache" works as a FIFO, so beginning of the second file is out of "Cache" by the the end of first prefault(). Workaround is to do double prefault() for segments, e.g. 1Gb. --=20 Andrey Zonov --H0tpX72hev2JCjPQh7huOmFm9x5V1gTBo-- --9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJXHtMdAAoJEBWLemxX/CvT2DEIAK39gGMSwIPss9vldU8k4PeZ 65+yy0+2G6HGyoh9hTVTuNX6fjENe1f+bNSOpMttokz3zX9nqKbSV3DTIeHaiuak ld1m/Czr6sTrMcguJm523TXqE2piMcD5RBU7Ju+8V8aDyjMJjP+FMxrC6/dpw17e PJox4P8OxY5lTOeSOb/Z0RjmIQZsWVk6WbuifBBy+D9edHlkr5Tplwnw+U+kfRsO 5Dslf77qJ1GQiB6CgYUCrBhvMHej9dRNVnLFqrVym6bFbyTxQa69g1x+XPtM8oFf BRMAmMhJmbiMEpR85WR/vO0V1rH8AkFsrHwFsYw1OkJz5vvYso7uN28jwlVQOfI= =mHsu -----END PGP SIGNATURE----- --9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0--