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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 96A10C433DB for ; Thu, 18 Mar 2021 08:55:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 24B7864F18 for ; Thu, 18 Mar 2021 08:55:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24B7864F18 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A96B36B0072; Thu, 18 Mar 2021 04:55:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A461B6B0073; Thu, 18 Mar 2021 04:55:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 899BD6B0074; Thu, 18 Mar 2021 04:55:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id 69A1F6B0072 for ; Thu, 18 Mar 2021 04:55:12 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1EE2D180260E7 for ; Thu, 18 Mar 2021 08:55:12 +0000 (UTC) X-FDA: 77932385664.17.B1B4A8C Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf20.hostedemail.com (Postfix) with ESMTP id 94982D7 for ; Thu, 18 Mar 2021 08:55:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616057710; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=a/4pFDfP/glft/+5Jx7HbMWg7z3f0/MvYTeDWR+6SiE=; b=U3AGjFN9o3XLqj4JkDySjo5GVRubTzteN+lNS6aZXaR/pEPe04UN590LXcbv8O7pkSvgs3 X+QO+cjZpbYUkL5sWZg5GkG7uiCVYSozBdbxk04ej/5gk+vHNZEkEIr2U8xpo06giuag9w 2zax6K2cL8LfUrdRwa7PrPtUVYkglh0= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 88ABEACC6; Thu, 18 Mar 2021 08:55:10 +0000 (UTC) Date: Thu, 18 Mar 2021 09:55:09 +0100 From: Michal Hocko To: Oscar Salvador Cc: David Hildenbrand , Andrew Morton , Vlastimil Babka , Muchun Song , Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 5/5] mm,page_alloc: Drop unnecessary checks from pfn_range_valid_contig Message-ID: References: <20210317111251.17808-1-osalvador@suse.de> <20210317111251.17808-6-osalvador@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: uggf6a4z3qe9xdqdnh8m4dx1e8d998qu X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 94982D7 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616057711-687569 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 Thu 18-03-21 09:44:19, Oscar Salvador wrote: > On Wed, Mar 17, 2021 at 04:03:06PM +0100, Michal Hocko wrote: > > > alloc_contig_pages() vs. alloc_contig_range(). The patches are active for > > > virtio-mem and CMA AFAIKS. > > > > yeah, I meant to say "are not actually fully active". > > We could place this patch earlier in this patchset. > The only thing is that we would lose the prevalidation (at leat for > HugeTLB page) which is done upfront to find later on that we do not > support hugetlb handling in isolate_migratepates_block. > So the bad thing about placing it earlier, is that wrt. hugetlb pages, > alloc_gigantic_page will take longer to fail (when we already know that > will fail). >From a bisactability POV this shouldn't be a major concern. If you are too worried then just drop the HugePage check in the patch allowing to migrate free hugetlb pages. It is unlikely that somebody will run with that patch alone but if the said patch introduces some sort of bug it would be good to bisect down to it. > Then we have the page_count check, which is also racy and > isolate_migratepages_block will take care of it. > So I guess can think of this patch as a preparatory patch that removes racy > checks that will be re-checked later on in the end function which does > the actual handling. TBH, I do not care much about the page count check. It is comletely orthogonal to the migration changes in this series. So both preparatory and follow up are ok. -- Michal Hocko SUSE Labs