From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755431AbbKDGF3 (ORCPT ); Wed, 4 Nov 2015 01:05:29 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:34849 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751354AbbKDGF1 (ORCPT ); Wed, 4 Nov 2015 01:05:27 -0500 Subject: Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) To: Andy Lutomirski , Minchan Kim References: <1446600367-7976-1-git-send-email-minchan@kernel.org> <1446600367-7976-2-git-send-email-minchan@kernel.org> <56399CA5.8090101@gmail.com> <56399D66.5010606@gmail.com> Cc: Hugh Dickins , Andrew Morton , Michael Kerrisk , Michal Hocko , "linux-mm@kvack.org" , KOSAKI Motohiro , "Kirill A. Shutemov" , Rik van Riel , Johannes Weiner , Linux API , Jason Evans , Shaohua Li , "linux-kernel@vger.kernel.org" , yalin.wang2010@gmail.com, Mel Gorman From: Daniel Micay Message-ID: <56399FFD.1050302@gmail.com> Date: Wed, 4 Nov 2015 01:04:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56399D66.5010606@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9mwiVDRwihtmkUwV9X70biccg5OpnXm2c" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9mwiVDRwihtmkUwV9X70biccg5OpnXm2c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/11/15 12:53 AM, Daniel Micay wrote: >> In the common case it will be passed many pages by the allocator. Ther= e >> will still be a layer of purging logic on top of MADV_FREE but it can = be >> much thinner than the current workarounds for MADV_DONTNEED. So the >> allocator would still be coalescing dirty ranges and only purging when= >> the ratio of dirty:clean pages rises above some threshold. It would be= >> able to weight the largest ranges for purging first rather than logic >> based on stuff like aging as is used for MADV_DONTNEED. >=20 > I would expect that jemalloc would just start putting the dirty ranges > into the usual pair of red-black trees (with coalescing) and then doing= > purging starting from the largest spans to get back down below whatever= > dirty:clean ratio it's trying to keep. Right now, it has all lots of > other logic to deal with this since each MADV_DONTNEED call results in > lots of zeroing and then page faults. Er, I mean dirty:active (i.e. ratio of unpurged, dirty pages to ones that are handed out as allocations, which is kept at something like 1:8). A high constant cost in the madvise call but quick handling of each page means that allocators need to be more aggressive with purging more than they strictly need to in one go. For example, it might need to purge 2M to meet the ratio but it could have a contiguous span of 32M of dirty pages. If the cost per page is low enough, it could just do the entire range. --9mwiVDRwihtmkUwV9X70biccg5OpnXm2c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWOZ/9AAoJEPnnEuWa9fIqyRsP/ApuxErM7bPshCha4gdN1S75 TMXYV0q8K9MqUm5lK78cLTJNQUFM1CrFP8DiWHinL5322XqW/nEmbzWTSrQMBTdc vv6kt5twjJ+vPB5YpOFqPNpDVc6YNiMWlVzwqDJf8FoumULa1JtMQOpQDYVIIsHj DLr4A6otsEUaoZ0/sszJMJDc4hdU+gy05tvSihorOTn+ZwS/vteZhcANXtsNlt7f lYcf8LsUrWDwwgHAeuz5ghcvstw5pd9DmhmoAz7GykCTWG44toG0FjTYhyH8/5Vu fKZ9A+pgmSa8xrhVs6rrLSY0zEPzg0S9nJixaeXKEh5czQAj0kn5cCHqoKIpvtmj 0PWPX+LgSyankBK85nS+8va7d3uRk9ui3Sh9TwRhMYAoN+nJl9mwO+zxP22X60NR mPyrEo/HM2bnzjHT1H8onBMJU0e5k341AmLgIsEEZi/K375ql8wN7TX+/oMBTpr6 5K0AEYFZdAOfmgb4sKXk2jKFZUL6odcqbI7cgEvnWw2js4F/RTORuWWkHFdtKQ9E pxF07fjSwmR9dFCvOekJ34yq52LD8WXI/XEQ1sNv+eeI5drUfEu66Zns1rDgRoEm SNoJYL7hhvcOsE+HM6EPjzHshfE0fwc1Dr3t1YxGFHBNnDTBDbJ3jR3Lvhl/RVt7 H+lXFWurH2FImUYb7Trv =9mdk -----END PGP SIGNATURE----- --9mwiVDRwihtmkUwV9X70biccg5OpnXm2c--