From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4ACE0C3F2CF for ; Fri, 28 Feb 2020 03:42:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0A53A246A1 for ; Fri, 28 Feb 2020 03:42:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="PrwiOPtF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A53A246A1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 982A16B0005; Thu, 27 Feb 2020 22:42:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 933836B0006; Thu, 27 Feb 2020 22:42:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 848716B0007; Thu, 27 Feb 2020 22:42:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id 694BC6B0005 for ; Thu, 27 Feb 2020 22:42:53 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2795E180AD80F for ; Fri, 28 Feb 2020 03:42:53 +0000 (UTC) X-FDA: 76538139426.09.line27_3642bcb801b0c X-HE-Tag: line27_3642bcb801b0c X-Filterd-Recvd-Size: 3121 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Fri, 28 Feb 2020 03:42:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=SorkXSQyHVFqXiBzU6ChGVstv5nQC7vtybcab5vAzZQ=; b=PrwiOPtFyyIzy115nfdPW77hCd 2pCQCdbsaNz9X9vQFk1rhdEqJvGggUmOXriIAnfF98EIVos5VDeNA2nc3wFuXld3G+xMV2AKkgRdy NrwQOFsxfdpv6vO/Y1zt3rRLxxqySeehc62tv5RGVf7sAIHtLXgJG59+csJ/OTYMP1NxEH+UvQ/al MhwPsy4gMb5m9s63zmXXddeEXHedXvMzLwJsboi0MlFEDVWSjHkmsMcN60Qy3LPqm7iqiGhN8ZNfI ApqtIiyf083m1Cxujpp4PM030y06HGwps8F8Km0ZSZ6EeIJ7D53Nk6O9hi0aNjXv3+uThGdivtHie HKCVdJdw==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j7WY4-0006gR-7A; Fri, 28 Feb 2020 03:42:48 +0000 Date: Thu, 27 Feb 2020 19:42:48 -0800 From: Matthew Wilcox To: "Huang, Ying" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand , Mel Gorman , Vlastimil Babka , Zi Yan , Michal Hocko , Peter Zijlstra , Dave Hansen , Minchan Kim , Johannes Weiner , Hugh Dickins Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating Message-ID: <20200228034248.GE29971@bombadil.infradead.org> References: <20200228033819.3857058-1-ying.huang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200228033819.3857058-1-ying.huang@intel.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 28, 2020 at 11:38:16AM +0800, Huang, Ying wrote: > MADV_FREE is a lazy free mechanism in Linux. According to the manpage > of mavise(2), the semantics of MADV_FREE is, > > The application no longer requires the pages in the range specified > by addr and len. The kernel can thus free these pages, but the > freeing could be delayed until memory pressure occurs. ... > > Originally, the pages freed lazily by MADV_FREE will only be freed > really by page reclaiming when there is memory pressure or when > unmapping the address range. In addition to that, there's another > opportunity to free these pages really, when we try to migrate them. > > The main value to do that is to avoid to create the new memory > pressure immediately if possible. Instead, even if the pages are > required again, they will be allocated gradually on demand. That is, > the memory will be allocated lazily when necessary. This follows the > common philosophy in the Linux kernel, allocate resources lazily on > demand. Do you have an example program which does this (and so benefits)? If so, can you quantify the benefit at all?