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 E2633C25B47 for ; Fri, 27 Oct 2023 17:58:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 283ED6B0381; Fri, 27 Oct 2023 13:58:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 234196B0382; Fri, 27 Oct 2023 13:58:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FC616B03D9; Fri, 27 Oct 2023 13:58:00 -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 F112B6B0381 for ; Fri, 27 Oct 2023 13:57:59 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C222CC098B for ; Fri, 27 Oct 2023 17:57:59 +0000 (UTC) X-FDA: 81391999878.04.2F7B31A Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf28.hostedemail.com (Postfix) with ESMTP id 2F7CCC0004 for ; Fri, 27 Oct 2023 17:57:57 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=softfail (imf28.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698429478; 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: in-reply-to:in-reply-to:references:references; bh=tBuQ2De1uqk1UoE6hAufFkbWj9xENdiPywcicIetkqY=; b=t27hlJEH30qLpd0IA1zcTF8uBmTmA7F4aF5ENX2cnJfq8B0QzhkuC9logO1xvj/ysZnpLG mKHiSXiF7rCBn9ASnKfRc+8OIZgnuGiIR8IeIAUGVBm/Qk0sKHk7HiFI1TXcHfk0BUkK5p s15t1kNkyujBYbQMCsJufq+0BFKK1Sk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698429478; a=rsa-sha256; cv=none; b=hBDa25Z9VZv58ZJSxgT0ekMAnFmxZQbxiQpWWScfZLBMojXsTwg1FbUTx26zlnpnHUHF0t AJAmqeHtGXo9J7RJJg2aEEfIkYCACmxn0xIhxPSFbRsU8xd/V0iCQmB4mr2x78GvSqoP0C rEwBo0/k0l0PBZXo5PDMuD5BizTWpQs= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=softfail (imf28.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) Received: by gentwo.org (Postfix, from userid 1003) id BD2E348F4E; Fri, 27 Oct 2023 10:57:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id BC6E9489FB; Fri, 27 Oct 2023 10:57:56 -0700 (PDT) Date: Fri, 27 Oct 2023 10:57:56 -0700 (PDT) From: Christoph Lameter To: chengming.zhou@linux.dev cc: penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chengming Zhou Subject: Re: [RFC PATCH v3 0/7] slub: Delay freezing of CPU partial slabs In-Reply-To: <20231024093345.3676493-1-chengming.zhou@linux.dev> Message-ID: References: <20231024093345.3676493-1-chengming.zhou@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 2F7CCC0004 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 93dzag48ifnk9uatn9n7fh9rqkc4thuf X-HE-Tag: 1698429477-51195 X-HE-Meta: U2FsdGVkX19xxAzt5IGB+a7RJJBX1gRQS7aGlewsh5uRJqkOSABAAddFnpIhwtK9Iui6MjW42Utj1UhNT11wsHMlK5/ggUpl+7f5gExj8y0eGP/81qJg5pqfajLk6WkmNcoZUO1RSp9mLmUstGi8kVvzzyF9/60M/m+Q3VxhYxqNDpdxRyGQeLBruMOhFnmK6hUXw8kz89R97q5IzwopOEWFu0W6PhEMRov/4m55YWSo3zehutEM1eOg3P2Riy4ZZormOVyh53PXi7Y/RSiOAlfjBkD7OHD910CJmxKzCnnX9yQvtIkRNj7bvRQLuGZJhMD3AKZDc3+GwGl0rcZZU+rhX9gUo5cyFjXjK2S2/Tqbhcq/GBajLs2/brO0Gkkg8S0+C6GH7XAfMVdZD8BorYTfEiUcEwASlBqSQewZcp7PfLm5qhzNJKlFsH4+8f4zhWo4fdpyMnJIEjY861FUSNq4qmk77yof4v8NV5a7xujT8NlLpxRgGWXZQ0zZVLNil98GkPHkqrxh38EI+CNssGuHlqfjM56PJOymudGYiddBGoUpKwCB/vHO/RWxg6V74fZyxdsoEjEB2o6zdVDs+R7WhfIoNJBozmCr+U+Msmgmn7LabdLIDd3VRpHnsyt0F9jcBceyBO67egeeJ81dzXZs1jPUK8J9dqF8xGsynYtG4vKJFxAodoO/A6Dda8cA4Ho2D6Rm/o0/HBpW83Slh/5j+p1/LGZouj2+6gm1iQGFHoYIBonk5V6Cag4xN63YkEngXXiaHhB4ziAatvUs9cO2r3qaXNOg5C2tVvVlP5l/BmXrh4nTSrBz3ATbJhNLwFgqgubqSxTshDgkWDwRlHFSOln+iIpVOme6c6yggzQKTdNueccQAZ+m2F85eBdwXTymLTQraer9JSzjNeiyVoUUzbqZtTbiPUIrLCg/pV0JfgdsvGoMEbZB8rVbHgjefjgeljyAvskl9TFbmbD RerzKOt+ zE4Ya4/NZGycYqu3F4AtSn4d7J0DBeHI7T+pRp1C/ASME/5Dpj7zaNmWe2JbCjYzQ8JLo8nGii7/NAsQzwOsR61kDxR3VdnV9YAtECeIiYzkxiVA4nMUqKSD4y/hcZAADyza1r1qq8X5L35mz24RCXom7WXWbLrgw5nWj57ASfhWGsLg= 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 Tue, 24 Oct 2023, chengming.zhou@linux.dev wrote: > 2. Solution > =========== > We solve these problems by leaving slabs unfrozen when moving out of > the node partial list and on CPU partial list, so "frozen" bit is 0. > > These partial slabs won't be manipulate concurrently by alloc path, > the only racer is free path, which may manipulate its list when !inuse. > So we need to introduce another synchronization way to avoid it, we > reuse PG_workingset to keep track of whether the slab is on node partial > list or not, only in that case we can manipulate the slab list. > > The slab will be delay frozen when it's picked to actively use by the > CPU, it becomes full at the same time, in which case we still need to > rely on "frozen" bit to avoid manipulating its list. So the slab will > be frozen only when activate use and be unfrozen only when deactivate. I think we have to clear our terminology a bit about what a "frozen" slab is. Before this patch a frozen slab is not on the node partial list and therefore its state on the list does not have to be considered during freeing and other operations. The frozen slab could be actively allocated from. >From the source: * Frozen slabs * * If a slab is frozen then it is exempt from list management. It is not * on any list except per cpu partial list. The processor that froze the * slab is the one who can perform list operations on the slab. Other * processors may put objects onto the freelist but the processor that * froze the slab is the only one that can retrieve the objects from the * slab's freelist. * After this patch the PG_workingset indicates the state of being on the partial lists. What does "frozen slab" then mean? The slab is being allocated from? Is that information useful or can we drop the frozen flag? Update the definition?