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 BA445C433EF for ; Sun, 21 Nov 2021 14:11:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A3D46B0071; Sun, 21 Nov 2021 09:11:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 253F16B0072; Sun, 21 Nov 2021 09:11:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11B896B0073; Sun, 21 Nov 2021 09:11:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 038176B0071 for ; Sun, 21 Nov 2021 09:11:34 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C08CB184E6C9E for ; Sun, 21 Nov 2021 14:11:23 +0000 (UTC) X-FDA: 78833124846.16.7A61D19 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf27.hostedemail.com (Postfix) with ESMTP id 31877700009B for ; Sun, 21 Nov 2021 14:11:22 +0000 (UTC) Received: by mail-lf1-f45.google.com with SMTP id y26so67648099lfa.11 for ; Sun, 21 Nov 2021 06:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=MXSFPhaseqYOtnsP8ujd+X3T5Tm7xFW3PNONPWyJ+FU=; b=H/8YlfqM9jO9Vh5MDR2Vzsi9nggPI9Rz5ESXs9026G8w+q6r/iUGmLEpSp4lwECWIN exbuu8+tNEbITELpry0su2YtvuINZ7nYlVWjrAF0VCGm5yRk+SemXgjJmXxOZmHe5BND WIXk+3vuqZcyo4OGRbcnieC7WeH4k+59bjwMwY2iPdvuHZCskBgcyj0dir3gIzQi6q0L U4SGkErPmzvlN4m3ChOkjXiXOrc3wfuRYMJqRctHkahRIR5p8ujfx3clAAhV5BdR6A9q oECz3bcO027isSQabWQzGV+I4o8dCv0XKyehzZ2b+yF3CXGqKO2oySOTVltlsJ+7pSWI pMqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=MXSFPhaseqYOtnsP8ujd+X3T5Tm7xFW3PNONPWyJ+FU=; b=HxS5edxpwjgsWM+AW5re4CgtUx8NaXO2frtfzTn314m3vKITZmJAlQKED/bDgql/7o HDOXBQQmgyqIwWLkLjYvHFQnlp7AA4rcenWPek0UJQuoPkELwgM1+UeFDrhce4uxgxbC te/NofcPyb0QAaTvrL2gPPQPlc646yxEOYklqgoEsLuvrOqf+8O1B3FDdrjlGP+2F7LE 27189mWKZ202rAn3HRzXo9vLCiqA6iGAIjZTEJ6jXSW+AOumb3mBmBsVb9wI/Ezp+yxt TzckEnDtnlHI+ejMgtZ6adw0x+8Fd3SkI0oDP5zNbTPsPgZ6uf2MmSTU4oi8mfn08o4G gRUg== X-Gm-Message-State: AOAM530LtFLZ3HgGy58dVfjSzWRoDqkxTyZFj66J1B3x/hmbVy7Jro+C xaQJpjYEsN90Ik7NRHX4H+MA3mDqpR4jPhaG6kruDykYlYKrrA== X-Google-Smtp-Source: ABdhPJzDJq+EyDMaVQSjnooR7Jj8lHdDTyW5Z0mtcZSaGpIxymwPw9GkGu3H7RhS4yNUbZDF2Yq69VWF272lJljy810= X-Received: by 2002:ac2:4c42:: with SMTP id o2mr49797090lfk.504.1637503881464; Sun, 21 Nov 2021 06:11:21 -0800 (PST) MIME-Version: 1.0 From: Wonhyuk Yang Date: Sun, 21 Nov 2021 23:11:11 +0900 Message-ID: Subject: [Question] The necessity of transaction ID in SLUB. To: linux-mm@kvack.org Cc: Christoph Lameter , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 31877700009B X-Stat-Signature: wrmk1x48e9t9yz87jabs8j1i78yxn1gz Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="H/8YlfqM"; spf=pass (imf27.hostedemail.com: domain of vvghjk1234@gmail.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=vvghjk1234@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1637503882-16203 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: Hi all, I have a question about the necessity of slub's transaction id. I found that it was Introduced by quite old commit 8a5ec0ba42c4 ("Lockless (and preemptless) fastpaths for slub"). And this concept is still being used. By using the transaction ID, we can verify that there is no update and it isn't running on other cpu. But it seems like that we can do these things by comparing c->cpu_slab->freelist. Let's assume we don't use transaction id. If other slub events occurred, c->cpu_slab->freelist will be different generally. But even if other slub events occurred, c->cpu_slab->freelist can be the same. There is 2 cases, 1) c->cpu_slab->page is unfrozen and frozen by another cpu. (is it possible?) 2) c->cpu_slab->freelist == NULL In the first case, cpu_slab structure can be different. But updating freelist isn't a problem. In the second case, slab alloc's fast-path doesn't have to care about it. Because it will call __slab_alloc instead of cmpxchg In the slab free's fast-path, c->cpu_slab->freelist can be NULL. So we have to check whether slab page is changed by other events. We can do this by checking the cpu_slab's page like below. this_cpu_cmpxchg_double( s->cpu_slab->freelist, s->cpu_slab->page, object, page, next_object, s->cpu_slab->page) I feel that I missed something important. Please let me know if I missed something. Thanks.