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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E7D5C77B6E for ; Fri, 14 Apr 2023 09:52:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF6166B0072; Fri, 14 Apr 2023 05:52:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7D866B0075; Fri, 14 Apr 2023 05:52:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D460A6B0078; Fri, 14 Apr 2023 05:52:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C30B46B0072 for ; Fri, 14 Apr 2023 05:52:09 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9CCD5801BB for ; Fri, 14 Apr 2023 09:52:09 +0000 (UTC) X-FDA: 80679530778.13.85EE9A5 Received: from outbound-smtp27.blacknight.com (outbound-smtp27.blacknight.com [81.17.249.195]) by imf28.hostedemail.com (Postfix) with ESMTP id 88E70C0006 for ; Fri, 14 Apr 2023 09:52:07 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.195 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681465928; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K/JlqeakFLeUBbis3wJXbpbrOFi0zGE0jlxMvccZETA=; b=Py7fJVFN525GVQoLpEpcPfHgPClRSscAYVN33jRE+znrzt0FpFlNW4p0DTTrLjeP+do7Nc 4Y5xakO+jROBEU93Pe81zKvm0DPI087SQ6J9EJBJBI2aurHDgOhFA/U1ziBVYWny57/zR+ Msa0gP0tzGCI3v+pO+oHp4uQMcjiK0I= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.195 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681465928; a=rsa-sha256; cv=none; b=1J5Jad7tmfenRO211tkomM/SQkGU+XfErMf0CY993a6DVISnNkTau3CsSTtY5LfMVJ0Qi5 heMhC8GHzhKOknIZh/YNYv9QhkrX6n4wcr319cRn6cmLa3ZKVNM72TUdZW7T19dT1EvnjK W7AiCVxWibSMkyj+n/OUSY94AV2+8DA= Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp27.blacknight.com (Postfix) with ESMTPS id A068FCAE32 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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 88E70C0006 X-Stat-Signature: ah93b7mnqhoxe6pj1r46ug1hyqig9838 X-HE-Tag: 1681465927-738369 X-HE-Meta: U2FsdGVkX193+qOkkqt+jPYVYlmxeb2JffL6+77nzWN03D0Ye7zcTqU/q6+vvnZAleCTNf6Ly9WRfKu/MYoz3tVouLjL9Vzb2hqK3mOC2cxmNgG+qFL8J5PFB93PIhvwQh4W3e89VKjezFE4nUF+/NOyakSw9CuyE58YXjJrOP4gwxbdYLOzfc3iDGfTlLUGN+mDNQVHay50m0d4qNdId5o1DXuqyoi37v1KvCRlv1MbNo/ZB9K/eYrQhXKgbAb7ofwfIo4HNeI6PDVbbqctyqvPHbC6qEKn1/TYSPYqNLrJpob4vC8bGFXvpnM6xQiTei6TTgFePh/kpA+3yzeE1VOFTuXAE/ChYNCVDWl+uhp3+o16dy0v9urqIGSfotY2eD1r0ZuD4UQARCfOMWomB1kp4RvBJR9TjzWQs3nagGng7KAv6buiPImZYazaipTylRgasBO8sB8Z4Xo0SBl1wGxnKqOkvwx3HE6hmIWQGtjKHpio8HOiWT5j+EVK290GYSr+oVFVhJPQfqwigLd5vzXj3az3WRRxlWE+egntcVx5tAj6aYz8rfahKpO4dEQHXcwp09+Qz3okbp215rvZhvEREnwI4UIxBrLkvF8loa9QiCEZaKMImbnEpyrL6zTlu7cLge9rgalxybTg7eueKgBCqmd68QRv3sGYxA1RpSLfdtcqXoAP0F0yJ4hNfup5A3Wtb4UUBY24tqD5xgoZgv9A3r0zbsnF/3uyFguo29DFDUKPaTRYOC/jEvQpxLMczvwYZtBG/BpT/HivCRK7J60E4CrfBQp4xhYUyNUvCv9brJJ11aiO4uOIQP0YrcNZ6obfSPHlaHAhU+Y3yFJhuBawDIDllFz4RsjykTqFwDjsInzdc84UEqpSwTDlz7v0JEMzUsTkyedUMKHiwP0In9/Pox3Qtm2GzrnclyBbSo3DwRUoRUjRauPx9futoPXoAucy6DTPD5WRNq4ialQ g4yRE5mx rknq01mwd5sbvuxZIEHMdcAttW9bDk8fteULZmwl/CBCV0xUr68QRT3z1aKeBbE6bOIQuEXQNBcN9wRDb9py/K8ANFZ5OURVCmgdSNhrxRgvNfz2l+/IR05+/40Cni4fhwIPf1wfhRLMmwbjQABaZ4MdXN8bNtDgNjXMkREvwDCvbnCT+UUZMcYLvwZWRRsJ9fsSpiY7YtQ+9ch2c45YQcf6L1tDPCMK6pKm1AVqI7um5tF8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000610, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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