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 07CBCC001E0 for ; Wed, 2 Aug 2023 14:27:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62497280183; Wed, 2 Aug 2023 10:27:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D4D4280143; Wed, 2 Aug 2023 10:27:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C31E280183; Wed, 2 Aug 2023 10:27:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3E50D280143 for ; Wed, 2 Aug 2023 10:27:30 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A0DD4C0FD1 for ; Wed, 2 Aug 2023 14:27:29 +0000 (UTC) X-FDA: 81079392618.13.D1D1978 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf11.hostedemail.com (Postfix) with ESMTP id 8907E4002E for ; Wed, 2 Aug 2023 14:27:27 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690986447; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=h4lzHDiCflvcW1LF/LjpnwWTTofBAO6nB+k+9/ojIhM=; b=fFk1o4fwJfuM/0IcA50y4zftelW6M4aKKbpEYo/mqbcxc2XumRHLdW8wwC5IAPQEj81fD6 PMejvbobiYIFAI/l8qga7nhtzRGvYG1hAJn2JvvNAWKDa9KieLTVjScd4BgotZ6A9A6AOF mrW7RIaUnUQJcZ9OxDazxm94o0QrohU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690986447; a=rsa-sha256; cv=none; b=n2uf4qnw4Ye+gdgdMrfvBZIA5Si3vVPr8Ci6cFHS6D5D5E/rXFYu2HltHrHt1WGSK4/Dt+ xez1h3CuapUzAfcR3tZF1ysE3ly9C+1+Nb3O5pE7+XjeUfmprnNL96di4rsqnxtDun2PPS B2BnpZ66rrbQVJvNwLdlzVlL/bnRTkU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RGDjp4p31z6J6JC; Wed, 2 Aug 2023 22:23:42 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 2 Aug 2023 15:27:21 +0100 Date: Wed, 2 Aug 2023 15:27:20 +0100 From: Jonathan Cameron To: Vishal Verma CC: Andrew Morton , David Hildenbrand , Oscar Salvador , Dan Williams , Dave Jiang , , , , , Huang Ying , Dave Hansen , Aneesh Kumar K.V , Michal Hocko , Jeff Moyer Subject: Re: [PATCH v3 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory Message-ID: <20230802152720.00007160@Huawei.com> In-Reply-To: <20230801-vv-kmem_memmap-v3-2-406e9aaf5689@intel.com> References: <20230801-vv-kmem_memmap-v3-0-406e9aaf5689@intel.com> <20230801-vv-kmem_memmap-v3-2-406e9aaf5689@intel.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100001.china.huawei.com (7.191.160.183) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 8907E4002E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: e1yr9j8t51csnor95fudx7wr6uhnij9b X-HE-Tag: 1690986447-435660 X-HE-Meta: U2FsdGVkX1/3JF7RFEURhAK5RkZLT9INUlwgcjq3Kk5D/JZrDSZlkudY8eUSSmUH+7U/35bTXP5cN+Ce+a5wOfnIbYJEDKZz+YWDInMnrYVht5ciNwDKv8uKszTS1KR88J2ZXT1uof4MY6mNuMDe6RLHDe+9SsmVAscO7qiw+l0XyRPzrL8Utl1q6Qjks+Wi6LIrwNjO04siy5mOotVO09V3FbVuWhpAknlbXLeFNuIn8OW1YPCquS/9aTnfaAIUUpWXruoQCrbQdwUBD8wuOqcCvZfp7XSS8S7zAgCyDciL87oy1oaUmfu7i6Q/kZquSv2563EgG4k02YuJD4KAPLnybKGfKd6zsATYRELwhpS3ZK6pkUOqcpDFnueDW7BXTRganoa9VjfdrT5cqwLlirP354YqmJ3bwarkYKFlOjFmXDyvGSS7I+uJft7HvgIz9M0I6oNPdWanitRyWgJo7jLYzP0q7moVEqZ33tEmDQhOTpXt3L11wFBcZi9HxKn1/HiTpqEpPBg8bi/UqmVMyFyWqXYW6w72WzUlu6rbancyhAvSi5eeACV71uuOgzwKeVkxncl/x/Il8O706oC7EzCCNs9/GcWJ/gWGWyHe8jtaFyICcA09HXoNp1lSAymtoCMIg6lJqqoWOwrNcJIl6B4mnN4dAqJKFH7wfvceDFAw839fXfidiJg1Sn2WkB53YsVph/xaZZ/ugfbl7ldt8HgU6pQjUxZEIXwpcW8Ujih6BpgunVNwGJL+c0lvoX1CyP/P7oTc6eCB9Hjqs/ou4NvvxuSg5MSQMRonZ+mluuuCLBUxg2zmgbVP13H9ng+DwXTmyH0I/GsGgS1T4lz5dulDO+ONf5vSJ4iAK/yhrsCZzFNVJ2kpmrXfbKcKlGsklyL+JbowgHcwOb9ytAFKfI59lGzh1f9em9FZGZBYmVGhTWOXm+HpNqeBKJn5yCMeSvu6oU9tYcBn7y9WM13 OdEzr++j c2L65VuPxL+Yghk/qzubaRpfxAxpbVnOEEcBNcUkhZ4QC0VaS2ZeOu8YYGQ4YHBg0aiC0JPyFOVFiPMzrC4g2zN+9fxOdBG8Q38Dg9DQhGTg6YtIFhkBUcBT7SqJH2SVox3FuoVs6nQU9w4ayX+gIMXy0pJ+4tXaBmQqxnJbEbugh0UNA6i+WnQoDcXlHcZ4cNBBz1mO0ZD87YBhE5+HA4JuBKX5jpnrqyH4fYnpoJWIu/mwJ0DGOMhMc4TY+e4V72wpTUxXrWTZf6PjEL09pqx8HObBHHOaEZBs+Cpgm/W7lm2D3eYwAdixMwZVNorFUDkvCmZoUgNN9OMHHUoHMROEbA4fSDXr2qv5Rpl9dZSkpeSBouCs+oZ0XpbyJr1mqxs53b+mLF4gJxtKsm5dgnTdyKCMm3YDsDaCRnaPqm8U17npPpo0vFH1jgIcgKfnMZW3K 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 Tue, 01 Aug 2023 23:55:38 -0600 Vishal Verma wrote: > Large amounts of memory managed by the kmem driver may come in via CXL, > and it is often desirable to have the memmap for this memory on the new > memory itself. > > Enroll kmem-managed memory for memmap_on_memory semantics as a default. > Add a sysfs override under the dax device to opt out of this behavior. > > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Michal Hocko > Cc: Oscar Salvador > Cc: Dan Williams > Cc: Dave Jiang > Cc: Dave Hansen > Cc: Huang Ying > Signed-off-by: Vishal Verma Hi Vishal, In general looks fine to me. Just a question for potential discussion if didn't miss it in earlier versions. FWIW Reviewed-by: Jonathan Cameron Also, any docs need updating? Doesn't seem like the DAX ABI docs are present in Documentation/ABI so not sure where it should be updated. Jonathan > > @@ -1400,6 +1435,13 @@ struct dev_dax *devm_create_dev_dax(struct dev_dax_data *data) > dev_dax->align = dax_region->align; > ida_init(&dev_dax->ida); > > + /* > + * If supported by memory_hotplug, allow memmap_on_memory behavior by > + * default. This can be overridden via sysfs before handing the memory > + * over to kmem if desired. > + */ > + dev_dax->memmap_on_memory = true; If there are existing users, then this is a fairly significant change of defaults. Maybe it should be false and opt in rather than out? > + > inode = dax_inode(dax_dev); > dev->devt = inode->i_rdev; > dev->bus = &dax_bus_type;