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 7BF59C3F2CD for ; Tue, 3 Mar 2020 08:58:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 42FFD2146E for ; Tue, 3 Mar 2020 08:58:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42FFD2146E 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 E751E6B000A; Tue, 3 Mar 2020 03:58:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E25996B000C; Tue, 3 Mar 2020 03:58:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D154E6B000D; Tue, 3 Mar 2020 03:58:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0118.hostedemail.com [216.40.44.118]) by kanga.kvack.org (Postfix) with ESMTP id BABFE6B000A for ; Tue, 3 Mar 2020 03:58:08 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 69F58180AD801 for ; Tue, 3 Mar 2020 08:58:08 +0000 (UTC) X-FDA: 76553449056.04.whip91_813ff6f125549 X-HE-Tag: whip91_813ff6f125549 X-Filterd-Recvd-Size: 6394 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Mar 2020 08:58:08 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id p9so2132129wmc.2 for ; Tue, 03 Mar 2020 00:58:08 -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=o3nAJyS427GVNyXsslN2Pau0rWQbZoVpqZd5vhmDcbo=; b=WZd2mEDgynZb3ENKDK2S1x4wSUJWLs9haiN5/U6Q8DFqqhnY0P7CaiXhxWQl7aA4OY 9L0Cal2Uy8+Le5Yz+mMUMtwPTL8sgL2ZxbIjJpis4PgxtDhJM0oX3j4o2HtIhNeVO2+z qvduK2/6aw9z7x5VYUnoTSxmIx3Dr0Po2/JnCxeFemjIv7RwKgFnK5fpasY6oHbrqySo 4CVnUDnriKcqkkGU1eD3Fgfkp3Ow/rX16tdFlEtPB7tbTywLajwlJRm0QTTnLK2u08AC pFhprjCA1v7yKW2HI9qcH4hSBE3jaizQR+rLE0ThgcZvZRulsD3+X1/lI69cgtKRDXCl 03pQ== X-Gm-Message-State: ANhLgQ1UyqKhaVNPl+rTC6PWdzCqm3tXLbdJkxCouUyUpTlhcIZjIy45 wSKHcJ1dgZt+0Yj9RgpKYHs= X-Google-Smtp-Source: ADFU+vsiSyGnf4NyZB71E2Xs4HRY4mlABNwI6En59X2klzFiehq8MNIym6DH+Eheu4txeMlKQO5MBA== X-Received: by 2002:a1c:2747:: with SMTP id n68mr3180805wmn.14.1583225887031; Tue, 03 Mar 2020 00:58:07 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id b10sm32893984wrw.61.2020.03.03.00.58.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2020 00:58:06 -0800 (PST) Date: Tue, 3 Mar 2020 09:58:05 +0100 From: Michal Hocko To: "Huang, Ying" Cc: Mel Gorman , David Hildenbrand , Johannes Weiner , Matthew Wilcox , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Zi Yan , Peter Zijlstra , Dave Hansen , Minchan Kim , Hugh Dickins , Alexander Duyck Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating Message-ID: <20200303085805.GB4380@dhcp22.suse.cz> References: <20200228034248.GE29971@bombadil.infradead.org> <87a7538977.fsf@yhuang-dev.intel.com> <871rqf850z.fsf@yhuang-dev.intel.com> <20200228094954.GB3772@suse.de> <87h7z76lwf.fsf@yhuang-dev.intel.com> <20200302151607.GC3772@suse.de> <87zhcy5hoj.fsf@yhuang-dev.intel.com> <20200303080945.GX4380@dhcp22.suse.cz> <87o8td4yf9.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o8td4yf9.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 16:47:54, Huang, Ying wrote: > Michal Hocko writes: > > > On Tue 03-03-20 09:51:56, Huang, Ying wrote: > >> Mel Gorman writes: > >> > On Mon, Mar 02, 2020 at 07:23:12PM +0800, Huang, Ying wrote: > >> >> If some applications cannot tolerate the latency incurred by the memory > >> >> allocation and zeroing. Then we cannot discard instead of migrate > >> >> always. While in some situations, less memory pressure can help. So > >> >> it's better to let the administrator and the application choose the > >> >> right behavior in the specific situation? > >> >> > >> > > >> > Is there an application you have in mind that benefits from discarding > >> > MADV_FREE pages instead of migrating them? > >> > > >> > Allowing the administrator or application to tune this would be very > >> > problematic. An application would require an update to the system call > >> > to take advantage of it and then detect if the running kernel supports > >> > it. An administrator would have to detect that MADV_FREE pages are being > >> > prematurely discarded leading to a slowdown and that is hard to detect. > >> > It could be inferred from monitoring compaction stats and checking > >> > if compaction activity is correlated with higher minor faults in the > >> > target application. Proving the correlation would require using the perf > >> > software event PERF_COUNT_SW_PAGE_FAULTS_MIN and matching the addresses > >> > to MADV_FREE regions that were freed prematurely. That is not an obvious > >> > debugging step to take when an application detects latency spikes. > >> > > >> > Now, you could add a counter specifically for MADV_FREE pages freed for > >> > reasons other than memory pressure and hope the administrator knows about > >> > the counter and what it means. That type of knowledge could take a long > >> > time to spread so it's really very important that there is evidence of > >> > an application that suffers due to the current MADV_FREE and migration > >> > behaviour. > >> > >> OK. I understand that this patchset isn't a universal win, so we need > >> some way to justify it. I will try to find some application for that. > >> > >> Another thought, as proposed by David Hildenbrand, it's may be a > >> universal win to discard clean MADV_FREE pages when migrating if there are > >> already memory pressure on the target node. For example, if the free > >> memory on the target node is lower than high watermark? > > > > This is already happening because if the target node is short on memory > > it will start to reclaim and if MADV_FREE pages are at the tail of > > inactive file LRU list then they will be dropped. Please note how that > > follows proper aging and doesn't introduce any special casing. Really > > MADV_FREE is an inactive cache for anonymous memory and we treat it like > > inactive page cache. This is not carved in stone of course but it really > > requires very good justification to change. > > If my understanding were correct, the newly migrated clean MADV_FREE > pages will be put at the head of inactive file LRU list instead of the > tail. So it's possible that some useful file cache pages will be > reclaimed. This is the case also when you migrate other pages, right? We simply cannot preserve the aging. -- Michal Hocko SUSE Labs