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=-1.0 required=3.0 tests=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 997A1C3F2CD for ; Tue, 3 Mar 2020 08:19:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 69E982072A for ; Tue, 3 Mar 2020 08:19:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 69E982072A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F2E6A6B0005; Tue, 3 Mar 2020 03:19:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB72F6B0006; Tue, 3 Mar 2020 03:19:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7F016B0007; Tue, 3 Mar 2020 03:19:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id BBCE56B0005 for ; Tue, 3 Mar 2020 03:19:32 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 99481181AC9B6 for ; Tue, 3 Mar 2020 08:19:32 +0000 (UTC) X-FDA: 76553351784.23.girl68_534af66f9362c X-HE-Tag: girl68_534af66f9362c X-Filterd-Recvd-Size: 4254 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Mar 2020 08:19:32 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id h9so2175979wrr.10 for ; Tue, 03 Mar 2020 00:19:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=z04jPTegah1x+XyJrZIvWmznvuMyEVD5pNJ2ECVbFc8=; b=iaikcR+c6sf3/8+nbZ6cJfh1wiE6uzR+K9uqvTkq6DkeZnwBK54geObcJTEm7H6WzD p1Sbrc4Vl7H7Aq4K76/05cD6vmFHMx0Dw2XA2Seil1opjJpkLMQgtA0MtmBZXvFTSf8h 99C6ubgS50ulQ4Rn0h68z1V/WUh5T2h3VuNECFDZ427o5Eq1MM8V0XmGA6BOH29120GL i4/6siN6SDd22Wnm0EJ4IStMpUo3DzWKeWxq3aTxMVNpiXNf56DkO9jKToj619G6NgY1 7M3NF9BTS5W3vR1iSqvRKLHqfXI1AB/roF2xxTj8+mSW0UXr8eKNO34UgsWnI9E8sp9j iZqg== X-Gm-Message-State: ANhLgQ2/3HcYfEj2I7WOkxXUhr+YsDj7lbdxxpO/mGJpRfnAbht7uPj4 xg7PDK7Omkj6gtKpXuzeoJI= X-Google-Smtp-Source: ADFU+vv6QbXmtXGG61XzfcFiKGH/M/nZOVa7e43A2+0bzNzWl0PZIWEdoP3t7WXQKHJWXHOegxU+EA== X-Received: by 2002:a5d:4d8c:: with SMTP id b12mr4172049wru.253.1583223571141; Tue, 03 Mar 2020 00:19:31 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id k16sm33014397wrd.17.2020.03.03.00.19.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2020 00:19:30 -0800 (PST) Date: Tue, 3 Mar 2020 09:19:29 +0100 From: Michal Hocko To: "Huang, Ying" Cc: David Hildenbrand , Matthew Wilcox , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman , Vlastimil Babka , Zi Yan , Peter Zijlstra , Dave Hansen , Minchan Kim , Johannes Weiner , Hugh Dickins , Alexander Duyck Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating Message-ID: <20200303081929.GY4380@dhcp22.suse.cz> References: <20200228033819.3857058-1-ying.huang@intel.com> <20200228034248.GE29971@bombadil.infradead.org> <87a7538977.fsf@yhuang-dev.intel.com> <871rqf850z.fsf@yhuang-dev.intel.com> <20200228095048.GK3771@dhcp22.suse.cz> <87d09u7sm2.fsf@yhuang-dev.intel.com> <20200302142549.GO4380@dhcp22.suse.cz> <874kv66x8r.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874kv66x8r.fsf@yhuang-dev.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 Tue 03-03-20 09:30:28, Huang, Ying wrote: [...] > Yes. mmap() can control whether to populate the underlying physical > pages. right because many usecases benefit from it. They simply know that the mapping will be used completely and it is worth saving overhead for #PF. See. there is a clear justification for that policy. > But for migrating MADV_FREE pages, there's no control, all pages > will be populated again always by default. Maybe we should avoid to do > that in some situations too. Now let's have a look here. It is the userspace that decided to mark MADV_FREE pages. It is under its full control which pages are to be freed lazily. If the userspace wants to move those pages then it is likely aware they have been MADV_FREE, right? If the userspace wanted to save migration overhead then it could either chose to not migrate those pages or simply unmap them right away. So in the end we are talking about saving munmap/MAMDV_DONTNEED or potentially more move_pages calls to skip over MADV_FREE holes. Which is all nice but is there any userspace that really does care? Because this is a fundamental question here and it doesn't make much sense to discuss this left to right unless this is clear. -- Michal Hocko SUSE Labs