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 412D4C433F5 for ; Tue, 23 Nov 2021 12:19:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD91F6B0071; Tue, 23 Nov 2021 07:18:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B6C9B6B0072; Tue, 23 Nov 2021 07:18:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A782C6B0073; Tue, 23 Nov 2021 07:18:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id 944166B0071 for ; Tue, 23 Nov 2021 07:18:50 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5B92D7B24C for ; Tue, 23 Nov 2021 12:18:40 +0000 (UTC) X-FDA: 78840098358.24.B2FF1AC Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf13.hostedemail.com (Postfix) with ESMTP id 4F80B1046318 for ; Tue, 23 Nov 2021 12:18:37 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id r26so3880671lfn.8 for ; Tue, 23 Nov 2021 04:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j6NcchU9erIvZGvzrKDxiiGALCRBFhiypsxp38W+eEc=; b=CPpSnPGKTIMDgcooIbt7zOGYGx9H/T0bYaSkqb7cWnl9qlkageZWDNBSUxPoezw2+q vA5JRScyPczXwrPau0/CLMF3hVuT2Zgj1XdOsE5WS/QZFH1E88EWFoMkoBXAX6FQWNu6 GkXA4vvyp0ZC4EdmVWyo08cE6uyeOfDid+F0FD9yarWoqDq7DfFbU9bNdoerrbAFV9cD hrGVbzLIYfD2jh5nI+3hrPiHKlBaRGeDPfG5hm+fpMQljg/cdaKsoQ9jQKe079WCJiFd Fzg/9JgEHxf3KcAdQHx7NbFAbRKh/dJxQe06n0uKNPh66jtXmx4f7teioVEiWh60x7gX qRpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j6NcchU9erIvZGvzrKDxiiGALCRBFhiypsxp38W+eEc=; b=en7UmctSWaikXusJvGex8bHVsUi6D3F53sz5QvuxbRmPOqhRBGwSiCrzpSKq9AqJTt n6TmAeQx7bMSDHVMgcY69CveCZ90QnDZ3D5ULmwGZFlCZSb4HtttmnOSr2xNThMjKMQZ 9PaqukyBNwI/FKcyVFUTyTMJM2iroN1NLXt3WzU9dJcl7Ge+d/pBWzGkgnEQjbeKGw80 87Y3nCve1oJR0CY3svUg4Z+tfruVdUp1JDmSssE6H9A9cAfg6GdWPhn+Tr7xFxz2jpKR 4Dl9R1pIfHLJDDTQ9gbDlk2VaP+ui5dF8tBFr68hoNbDWlPmEh9ZXuruQUrXGuOySqh8 26LA== X-Gm-Message-State: AOAM53379GYe2xM662E8wrL8hTzLzak4qaZh0gL81iE0hEEzxa/IJyFU gukzY2iGQJwFc3bWySvPe6mvjN3IU6Cdcm3e1n4= X-Google-Smtp-Source: ABdhPJyGe3wGrPxQzo0/Q0dUYlg52IK8myz4vOCGpkruZc/Wi8wr2N2NI4s/pq2e/SMAu3PhQJ7Sk1yC56/n9d1lc3g= X-Received: by 2002:ac2:4c42:: with SMTP id o2mr4363799lfk.504.1637669918304; Tue, 23 Nov 2021 04:18:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Wonhyuk Yang Date: Tue, 23 Nov 2021 21:18:28 +0900 Message-ID: Subject: Re: [Question] The necessity of transaction ID in SLUB. To: Christoph Lameter Cc: linux-mm@kvack.org, Joonsoo Kim Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4F80B1046318 X-Stat-Signature: du8ipd7uqqub14joodmdam1n17h8otxq Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=CPpSnPGK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of vvghjk1234@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=vvghjk1234@gmail.com X-Rspamd-Server: rspam02 X-HE-Tag: 1637669917-452115 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 Tue, Nov 23, 2021 at 6:38 PM Christoph Lameter wrote: > > > Do you mean that without TID, multiple cpu can race on one > > cpu_slab->freelist? > > > > How is it possible? As you know, cpu_slab is per-cpu variable and > > cpu_slab->freelist is accessed via "this_cpu_cmpxchg" in the area > > where preemption is enabled. > > That is the problem. Preemption is enabled. This means that slab_alloc can > be preempted at any time and continue to run on an arbitrary other > processor and also continue at an arbitrary time. It may also be > rescheduled on the processor it ran before after executing just one > instruction or so on another processor. Yes, that's why transaction id is made up of two part CPU id and event id (To guarantee there are no other events and migrations). And the guarantee is ultimately to protect cpu_slab->freelist. My point is, we can protect cpu_slab->freelist using only cpu_slab->freelist with less overhead. That's why I'm asking if there's any other reason for TID.