Date: Sat, 12 Oct 2013 17:14:40 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dmitry Sivachenko <trtrmitya@gmail.com> Cc: "hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: mmap() question Message-ID: <20131012141440.GN41229@kib.kiev.ua> In-Reply-To: <EB09D2E7-F870-4A3D-A071-83BD83C6985B@gmail.com> References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> <20131011051702.GE41229@kib.kiev.ua> <A5E3C0A2-F0D5-47B1-8992-4B9DA347C275@gmail.com> <20131012095919.GI41229@kib.kiev.ua> <EB09D2E7-F870-4A3D-A071-83BD83C6985B@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--zcUUBUpUFZiSJJc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 12, 2013 at 04:04:31PM +0400, Dmitry Sivachenko wrote: >=20 > On 12.10.2013, at 13:59, Konstantin Belousov <kostikbel@gmail.com> wrote: > >=20 > > I was not able to reproduce the situation locally. I even tried to start > > a lot of threads accessing the mapped regions, to try to outrun the > > pagedaemon. The user threads sleep on the disk read, while pagedaemon > > has a lot of time to rebalance the queues. It might be a case when SSD > > indeed makes a difference. > >=20 >=20 >=20 > With ordinary SATA drive it will take hours just to read 20GB of data fro= m disk because of random access, it will do a lot of seeks and reading spee= d will be extremely low. >=20 > SSD dramatically improves reading speed. >=20 >=20 > > Still, I see how this situation could appear. The code, which triggers > > OOM, never fires if there is a free space in the swapfile, so the > > absense of swap is neccessary condition to trigger the bug. Next, OOM > > calculation does not account for a possibility that almost all pages on > > the queues can be reused. It just fires if free pages depleted too much > > or free target cannot be reached. >=20 >=20 > First I tried with some swap space configured. The OS started to swap ou= t my process after it reached about 20GB which is also not what I expected:= what is the reason to swap out regions of read-only mmap()ed files? Is i= t the expected behaviour? >=20 How did you concluded that the pages from your r/o mappings were paged out ? VM never does this. Only anonymous memory could be written to swap file, including the shadow pages for the writeable COW mappings. I suspect that you have another 20GB of something used on the machine meantime. >=20 > >=20 > > Below is the prototype patch, against HEAD. It is not applicable to > > stable, please use HEAD kernel for test. >=20 >=20 > Thanks, I will test the patch soon and report the results. --zcUUBUpUFZiSJJc8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSWVlQAAoJEJDCuSvBvK1B3CIP/jUucHTlJZfE3Sx63ctQ4WvJ ZrJxgkETpmZLty7Llb73oJIw3jro4shk13zNVJS0wr1rJ9uBd/Nj6sChMb7cPI/V gN8s0tGV2RxNClnt5inWjGdWG0L8dadkru3m67wUr1xpvFCY3wL3XKTNO5qceoy+ 40Yyu+EFQG1leRS2lw8KoCDV3zhILHvs5CALQ0KXz5tyNVPcQfr6HxNtfDwoD4AI bavv4gPCyqBHVSam8M2Dzig63N4C0XFVwz/kg5FqLDlp4TvwHCjnn0/zFFEz+a6p gOtx7txeRmeXe6FJEGCYvHX+nush3dTSptUpH3/0skOtHcXMAgjnFbkmyGEL8C9q wPJGB+gv3DKpZtqF5aDUJeKLKXnC28gjz3yXQGcwkdMcZzwbsA/AjPdced0JIb18 ENUDxEqPEmBG82MBHJxz5gFmB2DW4ipp+dTg4z+Mf4/aSdbzz9SImuL8R2GtRgdm BTYXjfOjGGm6Chh4GYIn7vyRcCXTB7HXt7nHAHojYv9/oCqny4DW8YAzZvQcG3no z/e5VlvGWUQBiGaA8luaCUd0u4jGlC2PCZdGSPvmOdHM+zd0Dkno6sTZYHypm/zz b+5/RlE8GehceRY7hRFIgNJ1MbedsCtxN5/yyaspldkB2YnX0QcWtyJqOx1aD1t7 xh/NKbSxcJarZsSzMzEz =oOIh -----END PGP SIGNATURE----- --zcUUBUpUFZiSJJc8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131012141440.GN41229>