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.3 required=3.0 tests=BAYES_00, 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 A1D18C433DB for ; Mon, 11 Jan 2021 17:55:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0BA16223C8 for ; Mon, 11 Jan 2021 17:55:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BA16223C8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 72A6A8D004D; Mon, 11 Jan 2021 12:55:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D9608D004C; Mon, 11 Jan 2021 12:55:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EFE18D004D; Mon, 11 Jan 2021 12:55:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 494E08D004C for ; Mon, 11 Jan 2021 12:55:29 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 12B4C824556B for ; Mon, 11 Jan 2021 17:55:29 +0000 (UTC) X-FDA: 77694246378.13.side27_18175782750e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id E1AB218140B60 for ; Mon, 11 Jan 2021 17:55:28 +0000 (UTC) X-HE-Tag: side27_18175782750e X-Filterd-Recvd-Size: 3578 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 Jan 2021 17:55:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 10C21AB3E; Mon, 11 Jan 2021 17:55:27 +0000 (UTC) From: Vlastimil Babka Subject: Re: [RFC 0/3] mm, slab, slub: remove cpu and memory hotplug locks To: Christoph Lameter Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pekka Enberg , David Rientjes , Joonsoo Kim , Vladimir Davydov , Qian Cai , David Hildenbrand , Michal Hocko References: <20210106174029.12654-1-vbabka@suse.cz> Message-ID: <91f48b11-b6ff-39ab-947e-341920771e0f@suse.cz> Date: Mon, 11 Jan 2021 18:55:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 1/6/21 8:09 PM, Christoph Lameter wrote: > On Wed, 6 Jan 2021, Vlastimil Babka wrote: > >> rather accept some wasted memory in scenarios that should be rare anyway (full >> memory hot remove), as we do the same in other contexts already. It's all RFC >> for now, as I might have missed some reason why it's not safe. > > Looks good to me. My only concern is the kernel that has hotplug disabled. > Current code allows the online/offline checks to be optimized away. > > Can this patch be enhanced to do the same? Thanks, indeed I didn't think about that. But on closer inspection, there doesn't seem to be need for such enhancement: - Patch 1 adds the new slab_nodes nodemask, which is basically a copy of N_NORMAL_MEMORY. Without memory hotplug, the callbacks that would update it don't occur (maybe are even eliminated as dead code?), other code that uses the nodemask is unaffected wtf performance, it's just using a different nodemask for the same operations. The extra memory usage of adding the nodemask is negligible and not worth complicating the code to distinguish between the new nodemask and N_NORMAL_MEMORY depending on hotplug being disabled or enabled. - Patch 1 also restores slab_mutex lock in kmem_cache_shrink(). Commit 03afc0e25f7f removed it because the memory hotplug lock was deemed to be sufficient replacement, but probably didn't consider the case where hotplug is disabled and thus the hotplug lock is no-op. Maybe it's safe not to take slab_mutex in kmem_cache_shrink() in that case, but kmem_cache_shrink() is only called from a sysfs handler, thus a very cold path anyway. But, I found out that lockdep complains about it, so I have to rethink this part anyway... (when kmem_cache_shrink() is called from write to the 'shrink' file we already have kernfs lock "kn->active#28" and try to lock slab_mutex, but there's existing dependency in reverse order where in kmem_cache_create() we start with slab_mutex and sysfs_slab_add takes the kernfs lock, I wonder how this wasn't a problem before 03afc0e25f7f) - Patch 2 purely just removes calls to cpu hotplug lock. - Patch 3 only affects memory hotplug callbacks so nothing to enhance if hotplug is disabled