From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965824AbbKDWGc (ORCPT ); Wed, 4 Nov 2015 17:06:32 -0500 Received: from mail-qg0-f65.google.com ([209.85.192.65]:35927 "EHLO mail-qg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965397AbbKDWGa (ORCPT ); Wed, 4 Nov 2015 17:06:30 -0500 Subject: Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) To: Andy Lutomirski References: <1446600367-7976-1-git-send-email-minchan@kernel.org> <1446600367-7976-2-git-send-email-minchan@kernel.org> <56399CA5.8090101@gmail.com> Cc: Minchan Kim , 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 wang , Mel Gorman From: Daniel Micay X-Enigmail-Draft-Status: N1110 Message-ID: <563A813B.9080903@gmail.com> Date: Wed, 4 Nov 2015 17:05:47 -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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2IVeWpq2IbSSTeFp3TFicxabJLij5cBB9" 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) --2IVeWpq2IbSSTeFp3TFicxabJLij5cBB9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > With enough pages at once, though, munmap would be fine, too. That implies lots of page faults and zeroing though. The zeroing alone is a major performance issue. There are separate issues with munmap since it ends up resulting in a lot more virtual memory fragmentation. It would help if the kernel used first-best-fit for mmap instead of the current naive algorithm (bonus: O(log n) worst-case, not O(n)). Since allocators like jemalloc and PartitionAlloc want 2M aligned spans, mixing them with other allocators can also accelerate the VM fragmentation caused by the dumb mmap algorithm (i.e. they make a 2M aligned mapping, some other mmap user does 4k, now there's a nearly 2M gap when the next 2M region is made and the kernel keeps going rather than reusing it). Anyway, that's a totally separate issue from this. Just felt like complaining :). > Maybe what's really needed is a MADV_FREE variant that takes an iovec. > On an all-cores multithreaded mm, the TLB shootdown broadcast takes > thousands of cycles on each core more or less regardless of how much > of the TLB gets zapped. That would work very well. The allocator ends up having a sequence of dirty spans that it needs to purge in one go. As long as purging is fairly spread out, the cost of a single TLB shootdown isn't that bad. It is extremely bad if it needs to do it over and over to purge a bunch of ranges, which can happen if the memory has ended up being very, very fragmentated despite the efforts to compact it (depends on what the application ends up doing). --2IVeWpq2IbSSTeFp3TFicxabJLij5cBB9 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 iQIcBAEBCAAGBQJWOoE7AAoJEPnnEuWa9fIqY8cP/i3Vush0x4uyrzNPqvIVcxOf Z+RF1KG7P7XeVO2g3M+h8Mx1klWsgnKJHjOw9v7UU4LEn9kmioiTXs4KgjBebVap RJhhBDqlqoIm83ktfRAN2/hL/gfW3IUBmWZUv64YR7JD9w3O4RcbEv85HcXplQlC 0/kb5PasDsuXu0lWmAhEQO1ebKssnX3OryUxO6MNKGPlL73kXd1K2WOu9b4xtlWp 3M0iWJ7An4ItkV1vFh94WB22Ix2uwhqnC+I4p1SbZiivhGDd8lHDP1CIW/mAbYpS wIV0srQSYIwF66fnaExtRBdxVPzxyYsyMXf8TBO/XoPrm6Nh8Q5k438AbSsslzAb 6fqDoKVgz6ZEBsqJKSbrbGw6rSHtMLQLGTUDlBj5Z9jJU4IPNVf0Y1lyO8xNNN40 rJLBzcpCu0LiGzBJMIwUxSQb2Cze8QUmGd/+k17BbE26/9MjaZWrD4S7XANFbhL2 NYSBnemJsjFrz9waiI/pE4Q/qpramCDpdWwN7l3uO8auzVwn1NVmdo6pCLV5nSrZ MaRYavbmf+fFZmZ0/ptqVQG7HAN0dyjHuLVtSjGerj/o2cQ6MB0ibabqOEs9FB54 7xL3i2JycJn5Pk9TsSZHh1fxI2QNM70ltADzH8fG/Qprne3dzU0TqBskXpmy0et+ vNEz9RtJG8JKLuHkv26d =X3NF -----END PGP SIGNATURE----- --2IVeWpq2IbSSTeFp3TFicxabJLij5cBB9--