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 AAFE1C00144 for ; Mon, 1 Aug 2022 06:55:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FBC48E0002; Mon, 1 Aug 2022 02:55:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25D878E0001; Mon, 1 Aug 2022 02:55:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 089838E0002; Mon, 1 Aug 2022 02:55:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E519F8E0001 for ; Mon, 1 Aug 2022 02:55:26 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A1FB0A0862 for ; Mon, 1 Aug 2022 06:55:26 +0000 (UTC) X-FDA: 79750112652.12.B606162 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf12.hostedemail.com (Postfix) with ESMTP id D8D424004C for ; Mon, 1 Aug 2022 06:55:25 +0000 (UTC) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2716GSuR026514; Mon, 1 Aug 2022 06:55:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=5lB1ezmMHWY9mUEduax8LA8Wsmh5JZbmItaixuoFlW8=; b=SKuIu9SFBca73XptERrgE1ceOX9zfoS+wKViQ2+yhwoR7yKHPIM1dNaQjzuyKdIbW6lv rJ4do8vj7RkI5PaOfrZA0L9sYKHlTcuEvSydATXxmi3gESO2U658Iag7tgrCuG/pdEOU fKpoNSz4KhUPcLbzFRHtv14q+xNpcO2UsGxb802c2b88yJbtcwU74Xmcz/G5VY4HkOgl +2UT74REUQTpB0p64no5uVgHaDbsQf6UTXjyzEO6lzB5HGuqOfg32sQeVAD3X2vjAPDg 76AMA7NggcaJGS2JOoJpasLNyvVT7iw61v/YlvQk/PpicSploT0GQ+lBFj7ioAv6kdOi yA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hp6vgw2ct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Aug 2022 06:55:15 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2716dfUf019153; Mon, 1 Aug 2022 06:55:14 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hp6vgw2bh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Aug 2022 06:55:14 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2716puYH028433; Mon, 1 Aug 2022 06:55:12 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma04ams.nl.ibm.com with ESMTP id 3hmv98htru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Aug 2022 06:55:11 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2716tOJG32768364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 1 Aug 2022 06:55:24 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7D139AE045; Mon, 1 Aug 2022 06:55:09 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 04D1EAE051; Mon, 1 Aug 2022 06:55:06 +0000 (GMT) Received: from [9.43.22.209] (unknown [9.43.22.209]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 1 Aug 2022 06:55:05 +0000 (GMT) Message-ID: <1aba0c44-b096-8c75-8086-62d3cffc08b3@linux.ibm.com> Date: Mon, 1 Aug 2022 12:25:04 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v11 4/8] mm/demotion/dax/kmem: Set node's abstract distance to MEMTIER_ADISTANCE_PMEM Content-Language: en-US To: "Huang, Ying" Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Wei Xu , Yang Shi , Davidlohr Bueso , Tim C Chen , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Johannes Weiner , jvgediya.oss@gmail.com References: <20220728190436.858458-1-aneesh.kumar@linux.ibm.com> <20220728190436.858458-5-aneesh.kumar@linux.ibm.com> <875yjgmocg.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bkt8s7w9.fsf@linux.ibm.com> <87k07slnt7.fsf@yhuang6-desk2.ccr.corp.intel.com> <87tu6wk0q5.fsf@yhuang6-desk2.ccr.corp.intel.com> <826fbdbc-219f-8f4a-7373-41c718287533@linux.ibm.com> <87les8jwpu.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Aneesh Kumar K V In-Reply-To: <87les8jwpu.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: SvZniomhhLx0an3BIJRSHFFQV8FDUJ5E X-Proofpoint-GUID: lU17vtRQGH5hmm26dL7Gx5Mcmz_Pcp-B X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-01_02,2022-07-28_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1015 adultscore=0 malwarescore=0 mlxscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208010033 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659336926; 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:dkim-signature; bh=5lB1ezmMHWY9mUEduax8LA8Wsmh5JZbmItaixuoFlW8=; b=yR0Nbddp+8k0gSuyl4PUpzY3xdo1KYUQnaP8876XFbXq0uMyrNGutaE2nrwpHUQwJQSykS 1st7oFwlhyFjMrHtR3ij+REXpkE3JWZ4tdM9px1XHCPoGHElvrCtcQBJe8SXcCqxbaG+uH 9A2BnvdAzeVMJGIz0RlXzotjjuNMF3A= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=SKuIu9SF; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf12.hostedemail.com: domain of aneesh.kumar@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=aneesh.kumar@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659336926; a=rsa-sha256; cv=none; b=eWzvKK4v7vRiV9hNXaFFVKrrKWDWW4tDg46ZekquPgAZrtJtJ/Q1Rnc2RHYbnP7gXOfiyi rCHdSVv6b6vszDiR/S74El56SXZxcNBzVWfkuBwZ+wRWFyO3t2Jirqj5IPZktAWwQ67SEV W0LuWmzKeeTyEIGVs71s7VeYNMOUgBs= X-Rspamd-Server: rspam02 X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=SKuIu9SF; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf12.hostedemail.com: domain of aneesh.kumar@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=aneesh.kumar@linux.ibm.com X-Stat-Signature: urutjybi3ou98ubgsbdh6cixk5ma5eg9 X-Rspamd-Queue-Id: D8D424004C X-HE-Tag: 1659336925-657343 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 8/1/22 12:07 PM, Huang, Ying wrote: > Aneesh Kumar K V writes: > >> On 8/1/22 10:40 AM, Huang, Ying wrote: >>> Aneesh Kumar K V writes: >>> >>>> On 8/1/22 7:36 AM, Huang, Ying wrote: >>>>> "Aneesh Kumar K.V" writes: >>>>> >>>>>> "Huang, Ying" writes: >>>>>> >>>>>>> "Aneesh Kumar K.V" writes: .... >>>> >>>> With the module unload, it is kind of force removing the usage of the specific memtype. >>>> Considering module unload will remove the usage of specific memtype from other parts >>>> of the kernel and we already do all the required reset in memory hot unplug, do we >>>> need to do the clear_node_memory_type above? >>> >>> Per my understanding, we need to call clear_node_memory_type() in >>> dev_dax_kmem_remove(). After that, we have nothing to do in >>> dax_kmem_exit(). >>> >> >> Ok, I guess you are suggesting to do the clear_node_memory_type even if we fail the memory remove. > > Can we use node_memory_types[] to indicate whether a node is managed by > a driver? > > Regardless being succeeded or failed, dev_dax_kmem_remove() will set > node_memory_types[] = NULL. But until node is offlined, we will still > keep the node in the memory_dev_type (dax_pmem_type). > > And we will prevent dax/kmem from unloading via try_module_get() and add > "struct module *" to struct memory_dev_type. > Current dax/kmem driver is not holding any module reference and allows the module to be unloaded anytime. Even if the memory onlined by the driver fails to be unplugged. Addition of memory_dev_type as suggested by you will be different than that. Page demotion can continue to work without the support of dax_pmem_type as long as we keep the older demotion order. Any new demotion order rebuild will remove the the memory node which was not hotunplugged from the demotion order. Isn't that a much simpler implementation? -aneesh