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=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 1AE51C433E0 for ; Wed, 10 Feb 2021 12:17:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8AEF464E2A for ; Wed, 10 Feb 2021 12:17:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8AEF464E2A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 07B1B6B0006; Wed, 10 Feb 2021 07:17:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 02BE76B006C; Wed, 10 Feb 2021 07:17:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E83CE6B0071; Wed, 10 Feb 2021 07:17:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id D247D6B0006 for ; Wed, 10 Feb 2021 07:17:35 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9D90A141EF for ; Wed, 10 Feb 2021 12:17:35 +0000 (UTC) X-FDA: 77802258870.02.1AB47BC Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf21.hostedemail.com (Postfix) with ESMTP id A9959E0001AF for ; Wed, 10 Feb 2021 12:17:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E7F4EAC97; Wed, 10 Feb 2021 12:17:33 +0000 (UTC) Subject: Re: [PATCH] mm: remove lru_add_drain_all in alloc_contig_range To: Oscar Salvador , David Hildenbrand Cc: Minchan Kim , Andrew Morton , linux-mm , LKML , Michal Hocko References: <20210209175048.361638-1-minchan@kernel.org> <20210209190332.GA3363@localhost.localdomain> From: Vlastimil Babka Message-ID: <49491777-6d61-db4d-5e90-7a8b9045faca@suse.cz> Date: Wed, 10 Feb 2021 13:17:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210209190332.GA3363@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A9959E0001AF X-Stat-Signature: srb9hdqfko8x31kahksnxwh1fdd3xz45 Received-SPF: none (suse.cz>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1612959454-9646 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 2/9/21 8:03 PM, Oscar Salvador wrote: > On Tue, Feb 09, 2021 at 07:17:59PM +0100, David Hildenbrand wrote: >> I was expecting some magical reason why this is still required but I am not >> able to find a compelling one. Maybe this is really some historical >> artifact. >> >> Let's see if other people know why this call here still exists. > > I also stumbled upon this while working on adding hugetlb support for > alloc_acontig_range [1]. > I have to confess I puzzled me a bit. > > I saw it going back to when the function was first introduced by > > commit 041d3a8cdc18dc375a128d90bbb753949a81b1fb > Author: Michal Nazarewicz > Date: Thu Dec 29 13:09:50 2011 +0100 > > mm: page_alloc: introduce alloc_contig_range() > > > It does not make much sense to me. At this point our pages are free, so > we do not care about LRU handling here. > But I might be missing something. AFAICS, at the time page migration used putback_lru_page() to release the migration source page. This would put the page on lru pvec even if it was in fact not mapped anywhere anymore, and only the drain would actually free it. Seems Minchan optimized this in 2016 by c6c919eb90e0 ("mm: use put_page() to free page instead of putback_lru_page()") > [1] https://lore.kernel.org/linux-mm/20210208103935.GA32103@linux/T/#md651fc6e73c656105179382f92f8b2d6073051d1 > >