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 B38F1C38A2D for ; Wed, 26 Oct 2022 12:02:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 267AD8E0002; Wed, 26 Oct 2022 08:02:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 217AB8E0001; Wed, 26 Oct 2022 08:02:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12E0F8E0002; Wed, 26 Oct 2022 08:02:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 06A498E0001 for ; Wed, 26 Oct 2022 08:02:42 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CFBC6120F7A for ; Wed, 26 Oct 2022 12:02:41 +0000 (UTC) X-FDA: 80062963722.12.810982D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf22.hostedemail.com (Postfix) with ESMTP id AD88EC0003 for ; Wed, 26 Oct 2022 12:02:39 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5150A2207D; Wed, 26 Oct 2022 12:02:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666785758; 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=7e4B9MbvTUT94KALkUjhjJvQIZdQ+NZ1YEAmT1iPCak=; b=jBTiR2056OB5RGxD9Ep8aMTeGXS5/19j7BYWZI0qf+LmCe0xtKt55xiRpgEE2go33r73uC 5eh7cB3vp1wG4kENaaylmSyX7DN1ZbZO8B3OEYEYi7EFk/0qGkY5ur7GwwdeWhPt3oBFJI gN00fCK1RtvMjhrBBXrL04kYq18Dd5A= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666785758; 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=7e4B9MbvTUT94KALkUjhjJvQIZdQ+NZ1YEAmT1iPCak=; b=LCdWfDzVU66lhmR0RvgigsvxFNdO+VFt/FJY3rX/qAXyNZ6xS++brVDVFsdbKswA+qYVq9 FwdjFLb226jabWCg== Received: from suse.de (unknown [10.163.43.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 279362C141; Wed, 26 Oct 2022 12:02:34 +0000 (UTC) Date: Wed, 26 Oct 2022 13:02:32 +0100 From: Mel Gorman To: David Hildenbrand Cc: Doug Berger , Andrew Morton , Jonathan Corbet , Mike Rapoport , Borislav Petkov , "Paul E. McKenney" , Neeraj Upadhyay , Randy Dunlap , Damien Le Moal , Muchun Song , Vlastimil Babka , Johannes Weiner , Michal Hocko , KOSAKI Motohiro , Mike Kravetz , Florian Fainelli , Oscar Salvador , Joonsoo Kim , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 0/9] mm: introduce Designated Movable Blocks Message-ID: <20221026120232.bbhfwjm32qq4mh57@suse.de> References: <20221020215318.4193269-1-opendmb@gmail.com> <20221026105500.n6ddzqqf5ozjswsp@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666785760; 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:dkim-signature; bh=7e4B9MbvTUT94KALkUjhjJvQIZdQ+NZ1YEAmT1iPCak=; b=lHkmvYVSd6rmTIb/pnMp2Wc8/r0rImD+BSe+FQCg1V7MoFvz9nmrOXGeQMcaFtVZcObw6e jSYUinVwxMKkbnm99PXK3LodH/Wk4GIMIKzDK0A7MAqfZarYv4Kj7wshzaxNdKFDGTvxW3 s9XXNoRI7r+ExbDNvxkZ2ZzuHFkHQvE= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jBTiR205; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=LCdWfDzV; spf=pass (imf22.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666785760; a=rsa-sha256; cv=none; b=oCX9DKRnwYahOcYuQhN8xDaou618nKPDcHLFbYlYNIZiRHPnOP0RdHJVEstobIlDUzVE9c VYlZFoWQPWY8YvaD88CGG7R1rYy/sHF5AQef8vu0yukV5BhdUbzzm0Z9w7JLREQ0ef8IyC Pv03VAInPIixUjKc35e7HSHm+Z/hTow= Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jBTiR205; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=LCdWfDzV; spf=pass (imf22.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Stat-Signature: mzena3c6pr6jh6ga4t5ynth13g3mtw5s X-Rspamd-Queue-Id: AD88EC0003 X-Rspamd-Server: rspam07 X-Rspam-User: X-HE-Tag: 1666785759-461702 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 Wed, Oct 26, 2022 at 01:11:40PM +0200, David Hildenbrand wrote: > > In the appliance case, it doesn't matter if the intent is that "all > > application data should use high bandwidth memory where possible and > > the application phase behaviour is predictable" and that may very well > > work fine for the users of the Broadcom platforms with multiple memory > > controllers. It does not work at all for the general where access must > > be restricted to a subset of tasks in a general system that can only be > > controlled with memory policies. > > > > The high bandwidth memory should be representated as a NUMA node, optionally > > to create that node as ZONE_MOVABLE and relying on the zonelists to select > > the movable zone as the first preference. > > ... that boils down to my remark to tiered memory and eventually using > devdax to expose this memory to the system and letting the admin decide to > online it to ZONE_MOVABLE. Of course, that's just one way of doing it. > I don't see this approach being inherently bad as such, particularly in the appliance space where it is known in advance what exactly is running and what the requirements are. It's not automagical but it's not worse than specifying something like movablecore=100M@2G,100M@3G,1G@1024G. In either case, knowledge of the address ranges needing special treatment is required with the difference being that access to the special memory can be restricted by policies in the general case. -- Mel Gorman SUSE Labs