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 X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63D49C433E2 for ; Mon, 14 Sep 2020 08:40:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 93B1421548 for ; Mon, 14 Sep 2020 08:40:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="lL/OErse" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93B1421548 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C5FC06B0037; Mon, 14 Sep 2020 04:40:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0F256B005A; Mon, 14 Sep 2020 04:40:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFEBB6B005C; Mon, 14 Sep 2020 04:40:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id 95D6F6B0037 for ; Mon, 14 Sep 2020 04:40:01 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4A769181AEF09 for ; Mon, 14 Sep 2020 08:40:01 +0000 (UTC) X-FDA: 77261019402.25.smoke96_5616d0627107 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id E43E918179034 for ; Mon, 14 Sep 2020 08:40:00 +0000 (UTC) X-HE-Tag: smoke96_5616d0627107 X-Filterd-Recvd-Size: 6594 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Sep 2020 08:40:00 +0000 (UTC) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08E8X2YA029266; Mon, 14 Sep 2020 04:39:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=6hyBdWh5wrxsmd/YHbb6vywMegeCd8cNzzgph3fgj4Y=; b=lL/OErseBj++/I0oLL2VoqKAdguiPn23sb7mJa321Ztj0deHU7kZrmI4egz9GQ8hl3yU u++p0/i84FqtK1ddbFqk1K3p/HzOPIZ14Zz2j7vzcKz8SSPHdJCsSGSls5YghhhAy9xd naDo7CjHaUZM45h3PpcH8RmAgInxuHFeovVGzc60rzXTUfQnKElr2TAqkFOidaullVmP BR61klf7sqOotiQggpDgDDFDaQrkObnoxDEbXugda1oztcy/R/fuKNnFykX636tuxN55 SeeFT+q0cCfmY+sxMZOcRhUF96GWg5ZDKgg7OrZeXyHYE4s0h4Mqo5ihDM+MOzTKSCf+ 6Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33j4mvs2b9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Sep 2020 04:39:56 -0400 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 08E8XklS032661; Mon, 14 Sep 2020 04:39:56 -0400 Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0a-001b2d01.pphosted.com with ESMTP id 33j4mvs29s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Sep 2020 04:39:56 -0400 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 08E8bFTF029992; Mon, 14 Sep 2020 08:39:53 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma02fra.de.ibm.com with ESMTP id 33gny811ve-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Sep 2020 08:39:53 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 08E8dobx22872534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Sep 2020 08:39:50 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 77C4211C04A; Mon, 14 Sep 2020 08:39:50 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A5F0711C04C; Mon, 14 Sep 2020 08:39:49 +0000 (GMT) Received: from pomme.local (unknown [9.145.51.157]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 14 Sep 2020 08:39:49 +0000 (GMT) Subject: Re: [PATCH 2/3] mm: don't rely on system state to detect hot-plug operations To: Oscar Salvador , David Hildenbrand Cc: akpm@linux-foundation.org, mhocko@kernel.org, Greg Kroah-Hartman , linux-mm@kvack.org, "Rafael J . Wysocki" , nathanl@linux.ibm.com, cheloha@linux.ibm.com, Tony Luck , Fenghua Yu , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Michal Hocko References: <20200911134831.53258-1-ldufour@linux.ibm.com> <20200911134831.53258-3-ldufour@linux.ibm.com> <20200914081921.GA15113@linux> From: Laurent Dufour Message-ID: <678b596a-4d40-be88-daf0-c2edb16dd295@linux.ibm.com> Date: Mon, 14 Sep 2020 10:39:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200914081921.GA15113@linux> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-13_09:2020-09-10,2020-09-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 suspectscore=0 spamscore=0 priorityscore=1501 bulkscore=0 phishscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009140067 X-Rspamd-Queue-Id: E43E918179034 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable 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: Le 14/09/2020 =C3=A0 10:19, Oscar Salvador a =C3=A9crit=C2=A0: > On Mon, Sep 14, 2020 at 09:57:46AM +0200, David Hildenbrand wrote: >>> /* register memory section under specified node if it spans that no= de */ >>> +struct rmsun_args { >>> + int nid; >>> + enum memplug_context context; >>> +}; >=20 > Uhmf, that is a not so descriptive name. I do agree, but didn't have a better idea. Anyway this will disappear since the choosen direction is to have 2 callb= acks. >=20 >> Instead of handling this in register_mem_sect_under_node(), I >> think it would be better two have two separate >> register_mem_sect_under_node() implementations. >> >> static int register_mem_sect_under_node_hotplug(struct memory_block *m= em_blk, >> void *arg) >> { >> const int nid =3D *(int *)arg; >> int ret; >> >> /* Hotplugged memory has no holes and belongs to a single node. */ >> mem_blk->nid =3D nid; >> ret =3D sysfs_create_link_nowarn(&node_devices[nid]->dev.kobj, >> &mem_blk->dev.kobj, >> kobject_name(&mem_blk->dev.kobj)); >> if (ret) >> returnr et; >> return sysfs_create_link_nowarn(&mem_blk->dev.kobj, >> &node_devices[nid]->dev.kobj, >> kobject_name(&node_devices[nid]->dev.kobj)); >> >> } >> >> Cleaner, right? :) No unnecessary checks. >=20 > I tend to agree here, I like more a simplistic version for hotplug. >=20 >> One could argue if link_mem_section_hotplug() would be better than pas= sing around the context. >=20 > I am not sure if I would duplicate the code there. > We could just pass the pointer of the function we want to call to > link_mem_sections? either register_mem_sect_under_node_hotplug or > register_mem_sect_under_node_early? > Would not that be clean and clear enough? That would expose the register_mem_sect_under_node*() prototype to the ca= ller. I'm wondering if that would be cleaner than passing a MEMPLUG_* constant = value=20 to link_mem_sections() and let it choose the right callback.