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 27D0AC3F2D1 for ; Fri, 28 Feb 2020 09:50:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EA5A02087F for ; Fri, 28 Feb 2020 09:50:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA5A02087F 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 9D1056B0006; Fri, 28 Feb 2020 04:50:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9804C6B0007; Fri, 28 Feb 2020 04:50:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8973C6B0008; Fri, 28 Feb 2020 04:50:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0114.hostedemail.com [216.40.44.114]) by kanga.kvack.org (Postfix) with ESMTP id 71B736B0006 for ; Fri, 28 Feb 2020 04:50:52 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 41BD6824556B for ; Fri, 28 Feb 2020 09:50:52 +0000 (UTC) X-FDA: 76539066744.28.gate07_41c364645463c X-HE-Tag: gate07_41c364645463c X-Filterd-Recvd-Size: 4846 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Fri, 28 Feb 2020 09:50:51 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id r17so2202319wrj.7 for ; Fri, 28 Feb 2020 01:50:51 -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=JuWbxYpwiWaTODBjAB7HmLfrXVb5I46eoTle9ZgxHYU=; b=DLf1XGxcGG+7yr5dADdRfixhVd255S1NfSPlnwLK3SG31UaDoe6SSVU/HeWitz7VVL 56l7dZP1XEv7fh5U6Mt82W2BHS5sGvZmeMbDEDFkR5VqE2bkAUYmjAeYageYfdi8bHZ7 xXFtKVSMJjDLU7dQwc1+Wb1HUi6TYEI7zAXFqkhA464LaQSUyW/oYejHxWGw23xrJ3+i obmlSwH/bgZnnbvD5wEZTwXej9RN556Mh7PkOvnq8LzcfmE8XqHOcP4IZmINYyKCBCMm hn07mSzsjzKp5bTqN/8kfyqMKXcVVMrcDcGRKEZcvkRjF2h2qAbh/U8LoDHouLGYlF1u 1ytg== X-Gm-Message-State: APjAAAV4xjzwjpgdltYtRB39S/ztcz//tlk/3FvFevvpgzXjSsrZHQOe FDFjJxtbGeKQkhmk7E08bFM= X-Google-Smtp-Source: APXvYqwIQUNCJ2BsMMUuQyrovPwiMQUHrokSk8CJl0+LzcZb3GFLEfNaUKpUp7ylfhAcD4Ws2EnKEQ== X-Received: by 2002:a5d:6406:: with SMTP id z6mr4042600wru.294.1582883450512; Fri, 28 Feb 2020 01:50:50 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id d4sm1332086wmb.48.2020.02.28.01.50.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Feb 2020 01:50:49 -0800 (PST) Date: Fri, 28 Feb 2020 10:50:48 +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: <20200228095048.GK3771@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871rqf850z.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 Fri 28-02-20 16:55:40, Huang, Ying wrote: > David Hildenbrand writes: [...] > > E.g., free page reporting in QEMU wants to use MADV_FREE. The guest will > > report currently free pages to the hypervisor, which will MADV_FREE the > > reported memory. As long as there is no memory pressure, there is no > > need to actually free the pages. Once the guest reuses such a page, it > > could happen that there is still the old page and pulling in in a fresh > > (zeroed) page can be avoided. > > > > AFAIKs, after your change, we would get more pages discarded from our > > guest, resulting in more fresh (zeroed) pages having to be pulled in > > when a guest touches a reported free page again. But OTOH, page > > migration is speed up (avoiding to migrate these pages). > > Let's look at this problem in another perspective. To migrate the > MADV_FREE pages of the QEMU process from the node A to the node B, we > need to free the original pages in the node A, and (maybe) allocate the > same number of pages in the node B. So the question becomes > > - we may need to allocate some pages in the node B > - these pages may be accessed by the application or not > - we should allocate all these pages in advance or allocate them lazily > when they are accessed. > > We thought the common philosophy in Linux kernel is to allocate lazily. The common philosophy is to cache as much as possible. And MADV_FREE pages are a kind of cache as well. If the target node is short on memory then those will be reclaimed as a cache so a pro-active freeing sounds counter productive as you do not have any idea whether that cache is going to be used in future. In other words you are not going to free a clean page cache if you want to use that memory as a migration target right? So you should make a clear case about why MADV_FREE cache is less important than the clean page cache and ideally have a good justification backed by real workloads. -- Michal Hocko SUSE Labs