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 16AC3C00A8F for ; Tue, 24 Oct 2023 02:41:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61D556B016C; Mon, 23 Oct 2023 22:41:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CD836B016E; Mon, 23 Oct 2023 22:41:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BC476B0173; Mon, 23 Oct 2023 22:41:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 38D6C6B016C for ; Mon, 23 Oct 2023 22:41:27 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0DF06B5E35 for ; Tue, 24 Oct 2023 02:41:27 +0000 (UTC) X-FDA: 81378803814.06.CC8784C Received: from out-197.mta1.migadu.com (out-197.mta1.migadu.com [95.215.58.197]) by imf22.hostedemail.com (Postfix) with ESMTP id DE97FC0004 for ; Tue, 24 Oct 2023 02:41:24 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=F7ahZY0d; spf=pass (imf22.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.197 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698115285; 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=DTMaBMJj10j72PXuCPyuHbqbaXnXbH7yMFP0YeQy5dU=; b=yLAP+qaPbIpqKtAkXd8SqjpGiRZqQPXzfI1/ol4JCrq1jhYEqByiCsAXj7JvuqOclbuMgm TdFcJIfuW0NqNo1gzkLKtqpawvDJ/mwVykCo5W3re2UQTa3hpHQ3kq2A+e0QSa/UJi7sTq qxak87AfL2NglQ0f+l1Kxm7NjliwB7U= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=F7ahZY0d; spf=pass (imf22.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.197 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698115285; a=rsa-sha256; cv=none; b=qOatL6y9FX/BolThJyOk5VG20WVq0shHhnekm3x5xtIzlEdT2vV0IOJ8ZGNI+zlQpPp/gg kQXJSryCy+Zi0Q2cN9+cQnr8ldhqVpl7HaDFmD2eRdpCYjcx+hRMUAF6DOLvqU8FPUGJM8 tEVvvOxG0b2WZT7XSTmCNTp6eT/Fy2A= Message-ID: <217c52ba-3b06-488d-b21a-3d2dd62438a8@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1698115281; h=from:from: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=DTMaBMJj10j72PXuCPyuHbqbaXnXbH7yMFP0YeQy5dU=; b=F7ahZY0dgoGIXkXYwFWekobD2zj7iTWYeiV7CLbeNV3qlWmjg9gT2ga1RcqKl5j3b8qvfE 3wzHyH9RmBW5BAPpvmLdu1339yHmL7YU9Lek9g/ptbinj3bWPwyT0hlYQqv8+0pqATAK5+ xxx08X/QjBGzzhxEWrbW0wWTekZ67kw= Date: Tue, 24 Oct 2023 10:39:37 +0800 MIME-Version: 1.0 Subject: Re: [RFC PATCH v2 3/6] slub: Don't freeze slabs for cpu partial Content-Language: en-US To: Vlastimil Babka , cl@linux.com, penberg@kernel.org Cc: rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, willy@infradead.org, pcc@google.com, tytso@mit.edu, maz@kernel.org, ruansy.fnst@fujitsu.com, vishal.moola@gmail.com, lrh2000@pku.edu.cn, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chengming Zhou References: <20231021144317.3400916-1-chengming.zhou@linux.dev> <20231021144317.3400916-4-chengming.zhou@linux.dev> <79a879cc-f5f8-08ef-0afa-3688d433a756@suse.cz> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <79a879cc-f5f8-08ef-0afa-3688d433a756@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: DE97FC0004 X-Rspam-User: X-Stat-Signature: 1u6gnt4g59od384ke9k1yme95m7bzzqu X-Rspamd-Server: rspam01 X-HE-Tag: 1698115284-422194 X-HE-Meta: U2FsdGVkX1+ePToBdWKgmJbN/d2D0K8m/lhVdJmjS9jN4rjKAzHz8rv1WDClEAaoSApgmjjMLwB/q27oSqSoAPbm4VAQU1AihYG1xC0aMrV5dt2HlEAf3dzRp+A98CF+pjGe+G5s3gXltn+ZnacDTxbZzoxqGFfnJd2TWsVnixBFxNTpssPh3TCdALTDwo+gwII4d0B4zxwuD7mlxzBdWYk8XGxtkj5u4C0jZ2+OPacaBMC8tvicvz2ok6IS3yFQm9eCU8r2iC1jFGSrspOEf7GGlWoccpA/HhSW2F7GFJTWvdxQSqhaqDrmbzfb1JIbUZ0Y+11bkErhA+15Zkcfl8uxEZWksmfe0kC4wq15YG1yPk7fRSS9D9HXLgA7CmpSBHy/6xKLV8rEPLTwEIWnuaqyPMpx1KN/7nkdsUxKCmx6i9Mi+wGoY0UkE6LsrG8pttM54TVtDwBo+o7LkBV9YetavntHzRLNzkYgE3i6l2U8HeSnXz3Yu+GPjGephnwRSg8x7KJ9K9kJXFt9Jo2CsP46P8zOma0gm+CNCLxKYteBe9eb61INkTkmuMkaoZBc0yZmwNo+tbnBC88qn7CK7nsS5LGfgP5LlYbC71/2+13bFaNmsIjJ8vQIIOVYtXPiutzuVycDKITqPWB61gHoAck4A4xKIn5M61nSeedrHeIKNJbBUrINq/rZ5JV3L/WIK4ab1CESc8PhhTkZ7/MyvVQfWbk95J3oRcDV9vUqrienMUSkEJiRtlA7PL1UDPnYujvjJXf3z1E3+22z7qMa30IBikqcyaD+9TPXFF94syh//fGYEuBShVhw/RQSLU/jJfRb4Dj2dXT8lZPk5pHqCtXQdMmEen7WhhKfhwfljUDv2vXAL7jQY0i0Xlnulua/uGkc0ff12ycWkupnFx/h1FLK5ItPAnjzJbPscs8dZ7M4+q9cV6oZNX2T0hVhSUTWK6/aD5NTvXmQulKI2tw HszE1C+V cicl9nBVdVCPyXiNd9HdBermzcGC8gauYOFX4R76LAWVRrz2xO2nHBTxau30ax4ULzcrXC3gwuN0qnUOoArhXaaaZzIrUEDtYlvOhTvks5KqzlQD4GJiaW3+5C4jv/VvnNbbaUwhFT6trFd8nxhmxGbBWbXFGA2BKdIC5UHy43lUJEsGhIiDLUBmutJwNGUDHI4phdhld7XCgnSlT0d4beUYoFIUfBi28OfGm 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: List-Subscribe: List-Unsubscribe: On 2023/10/24 00:00, Vlastimil Babka wrote: > On 10/21/23 16:43, chengming.zhou@linux.dev wrote: >> From: Chengming Zhou >> >> Now we will freeze slabs when moving them out of node partial list to >> cpu partial list, this method needs two cmpxchg_double operations: >> >> 1. freeze slab (acquire_slab()) under the node list_lock >> 2. get_freelist() when pick used in ___slab_alloc() >> >> Actually we don't need to freeze when moving slabs out of node partial >> list, we can delay freeze to use slab freelist in ___slab_alloc(), so >> we can save one cmpxchg_double(). >> >> And there are other good points: >> >> 1. The moving of slabs between node partial list and cpu partial list >> becomes simpler, since we don't need to freeze or unfreeze at all. >> >> 2. The node list_lock contention would be less, since we only need to >> freeze one slab under the node list_lock. (In fact, we can first >> move slabs out of node partial list, don't need to freeze any slab >> at all, so the contention on slab won't transfer to the node list_lock >> contention.) >> >> We can achieve this because there is no concurrent path would manipulate >> the partial slab list except the __slab_free() path, which is serialized >> now. >> >> Note this patch just change the parts of moving the partial slabs for >> easy code review, we will fix other parts in the following patches. >> Specifically this patch change three paths: >> 1. get partial slab from node: get_partial_node() >> 2. put partial slab to node: __unfreeze_partials() >> 3. cache partail slab on cpu when __slab_free() > > So the problem with this approach that one patch breaks things and another > one fixes them up, is that git bisect becomes problematic, so we shouldn't > do that and instead bite the bullet and deal with a potentially large patch. > At some level it's unavoidable as one has to grasp all the moving pieces > anyway to see e.g. if the changes in allocation path are compatible with the > changes in freeing. > When possible, we can do preparatory stuff that doesn't break things like in > patches 1 and 2, maybe get_cpu_partial() could also be introduced (even if > unused) before switching the world over to the new scheme in a single patch > (and possible cleanups afterwards). So would it be possible to redo it in > such way please? Ok, I will change to this way. I didn't know how to handle this potentially large patch gracefully at first. Your detailed advice is very helpful to me, I will prepare all possible preparatory stuff, then change all parts over in one patch. > > > >> @@ -2621,23 +2622,7 @@ static void __unfreeze_partials(struct kmem_cache *s, struct slab *partial_slab) >> spin_lock_irqsave(&n->list_lock, flags); >> } >> >> - do { >> - >> - old.freelist = slab->freelist; >> - old.counters = slab->counters; >> - VM_BUG_ON(!old.frozen); >> - >> - new.counters = old.counters; >> - new.freelist = old.freelist; >> - >> - new.frozen = 0; >> - >> - } while (!__slab_update_freelist(s, slab, >> - old.freelist, old.counters, >> - new.freelist, new.counters, >> - "unfreezing slab")); >> - >> - if (unlikely(!new.inuse && n->nr_partial >= s->min_partial)) { >> + if (unlikely(!slab->inuse && n->nr_partial >= s->min_partial)) { >> slab->next = slab_to_discard; >> slab_to_discard = slab; >> } else { >> @@ -3634,18 +3619,8 @@ static void __slab_free(struct kmem_cache *s, struct slab *slab, >> was_frozen = new.frozen; >> new.inuse -= cnt; >> if ((!new.inuse || !prior) && !was_frozen) { >> - >> - if (kmem_cache_has_cpu_partial(s) && !prior) { >> - >> - /* >> - * Slab was on no list before and will be >> - * partially empty >> - * We can defer the list move and instead >> - * freeze it. >> - */ >> - new.frozen = 1; >> - >> - } else { /* Needs to be taken off a list */ >> + /* Needs to be taken off a list */ >> + if (!kmem_cache_has_cpu_partial(s) || prior) { >> >> n = get_node(s, slab_nid(slab)); >> /* >> @@ -3675,7 +3650,7 @@ static void __slab_free(struct kmem_cache *s, struct slab *slab, >> * activity can be necessary. >> */ >> stat(s, FREE_FROZEN); >> - } else if (new.frozen) { >> + } else if (kmem_cache_has_cpu_partial(s) && !prior) { >> /* >> * If we just froze the slab then put it onto the >> * per cpu partial list. > > I think this comment is now misleading, we didn't freeze the slab, so it's > now something like "if we started with a full slab...". Ok, will check and change these inconsistent comments by the way. Thanks!