Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp291815rwe; Fri, 14 Apr 2023 02:57:35 -0700 (PDT) X-Google-Smtp-Source: AKy350Y0RJIuq/vfDBaiB10MJXU925lY7s8Fs1AUCErKnvu6A95MXFAEpc/r7pOSSYLAmxVbHeHC X-Received: by 2002:a05:6a20:1592:b0:ec:8f81:e9f7 with SMTP id h18-20020a056a20159200b000ec8f81e9f7mr4644495pzj.16.1681466254923; Fri, 14 Apr 2023 02:57:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681466254; cv=none; d=google.com; s=arc-20160816; b=CXk7AN8zEwoDqo8zB/MKc3uXk4U6sPdsv8vfm0X5S2aSdqv3iFPOJYtGKugFvAEZvc +/oAyhgzHnX8Ahfyw5zgKdneudXFAkhiC1/eXIDoMPeDT14FCe1I8pO16ucLR3g+Nz54 HHxZO6ET/0hLGp503UmJTferY3fWbZT76iNDzUfSuS4NmLGzPr39AAit8EbxJ3Rxtfad Iat/olELc6z4LF/ONwWvCBXXjTBCtgrjbMZ/hShVzi5CL79c5tLGhFKb98FePtEFwY8c JDiJx2j4GfOx+ZxH6XJkM6IQtxGVQPFju0YpJNqualspCJNDVbQVmBB6XMz48vCP5vHJ m+dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=K/JlqeakFLeUBbis3wJXbpbrOFi0zGE0jlxMvccZETA=; b=CqhmlmuihfWkKtM1bsmG41A/0ruJnCOxySTqQDa6WQN/ZmkACJ9vyOLwzfixXs9MNK 6rPDvsy+OxPZH2XiKCJhKr690y2qnW4sBdo9Nme+5lsZrK3CGa6uOPemRqOA7VobucBa qeiG1NzcmwvkQvwl0XwOYc/qv2q4drqFJ2WgDpticlZDzykEiPsNE+eoNesPAOktbOsS wgvo91z/Oa/dySzuKEHAKCogHhU9XNQyu5OFsRAaHI99TAGp7mqnwdHTP3oxaF1NWyta RczLMgmtI3Qs4I0ScSO2Noha0JRrWD7W4tqRkYPP8e+QH93bDPxCDY0cYaPC1IHPd/0F Kfcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w5-20020a654105000000b0051254e55499si4257188pgp.245.2023.04.14.02.57.23; Fri, 14 Apr 2023 02:57:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229949AbjDNJwL (ORCPT + 99 others); Fri, 14 Apr 2023 05:52:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbjDNJwJ (ORCPT ); Fri, 14 Apr 2023 05:52:09 -0400 Received: from outbound-smtp02.blacknight.com (outbound-smtp02.blacknight.com [81.17.249.8]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71B9D72B3 for ; Fri, 14 Apr 2023 02:52:06 -0700 (PDT) Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp02.blacknight.com (Postfix) with ESMTPS id A1D21BACB2 for ; Fri, 14 Apr 2023 10:52:05 +0100 (IST) Received: (qmail 19672 invoked from network); 14 Apr 2023 09:52:05 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.21.103]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 14 Apr 2023 09:52:05 -0000 Date: Fri, 14 Apr 2023 10:52:04 +0100 From: Mel Gorman To: Michal Hocko Cc: Andrew Morton , Vlastimil Babka , Oscar Salvador , Yuanxi Liu , David Hildenbrand , Linux-MM , LKML Subject: Re: [PATCH] mm: page_alloc: Assume huge tail pages are valid when allocating contiguous pages Message-ID: <20230414095204.7fz6trkj5i4mzthz@techsingularity.net> References: <20230414082222.idgw745cgcduzy37@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 14, 2023 at 10:55:04AM +0200, Michal Hocko wrote: > On Fri 14-04-23 09:22:22, Mel Gorman wrote: > [...] > > + > > + /* > > + * Do not migrate huge pages that span the size of the region > > + * being allocated contiguous. e.g. Do not migrate a 1G page > > + * for a 1G allocation request. CMA is an exception as the > > + * region may be reserved for hardware that requires physical > > + * memory without a MMU or scatter/gather capability. > > + * > > + * Note that the compound check is race-prone versus > > + * free/split/collapse but it should be safe and result in > > + * a premature skip or a useless migration attempt. > > + */ > > + if (PageHuge(page) && compound_nr(page) >= nr_pages && > > + !is_migrate_cma_page(page)) { > > + return false; > > Is the CMA check working as expected? I didn't test it as I don't have a good simulator for CMA contraints which is still a mobile phone concern for devices like cameras. > The function sounds quite generic > and I agree that it would make sense if it was generic but it is used > only for GB pages in fact and unless I am missing something it would > allow to migrate CMA pages and potentially allocate over that region > without any possibility to migrate GB page out so the CMA region would > be essentially unusable for CMA users. It's used primarily for 1G pages but does have other users (debugging mostly, low priority). As it's advertised as a general API, I decided to treat it as such and that meant being nice to CMA if possible. If CMA pages migrate but can still use the target location then it should be fine. If a CMA can migrate to an usable location that breaks a device then that's a bug. > GB pages already have their CMA > allocator path before we get to alloc_contig_pages. Or do I miss > something? I don't think you missed anything. The CMA check is, at best, an effort to have a potentially useful semantic but it's very doubtful anyone will notice or care. I'm perfectly happy just to drop the CMA check because it's a straight-forward fix and more suitable as a -stable backport. I'm also happy to just go with a PageHuge check and ignore any possibility that a 2M page could be migrated to satisfy a 1G allocation. 1G allocation requests after significant uptime is a crapshoot at best and relying on them succeeding is unwise. There is a non-zero possibility that the latency incurred migrating 2M pages and still failing a 1G allocation could itself be classed as a bug with users preferring fast-failure of 1G allocation attempts. -- Mel Gorman SUSE Labs