Date: Mon, 25 Apr 2016 19:31:52 -0700 From: Andrey Zonov <zont@FreeBSD.org> To: Dmitry Sivachenko <trtrmitya@gmail.com>, hackers@freebsd.org Subject: Re: Strange memory management with mmap() Message-ID: <571ED318.1030402@FreeBSD.org> In-Reply-To: <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> References: <FDB6E0F9-A3FF-4194-83C1-A3121CBAE407@gmail.com> <3434ED75-7994-4E9E-9B06-FACCD7DC90FF@gmail.com> <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0 Content-Type: multipart/mixed; boundary="H0tpX72hev2JCjPQh7huOmFm9x5V1gTBo" From: Andrey Zonov <zont@FreeBSD.org> To: Dmitry Sivachenko <trtrmitya@gmail.com>, hackers@freebsd.org Message-ID: <571ED318.1030402@FreeBSD.org> Subject: Re: Strange memory management with mmap() References: <FDB6E0F9-A3FF-4194-83C1-A3121CBAE407@gmail.com> <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 <trtrmitya@gmail.com> wrote: >> >>> >>> On 16 =D0=B8=D1=8E=D0=BB=D1=8F 2015 =D0=B3., at 18:42, Dmitry Sivache= nko <trtrmitya@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?571ED318.1030402>