Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1149479pxb; Thu, 4 Mar 2021 04:46:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJz1+nGUjed7m0YkOC/m9Jn5TlaSoFmkV3nF02TGmJmqZz+POjaiLUEt/tu5MBDuDJmKVR56 X-Received: by 2002:a17:906:b14b:: with SMTP id bt11mr4173439ejb.162.1614862010818; Thu, 04 Mar 2021 04:46:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614862010; cv=none; d=google.com; s=arc-20160816; b=Z/lIsFsKQ5QQUQ/R2ZUostLxhmBM2ulMYrCCVY6vImdXwzW+mLHN9BU2l13EtRiTsA 3evVI1v+5APal1FOd/h6tTTaG+Q3s07w7nIDrbGZb9pBhPfBIl08CaF1hhudQ4R49uaM 56wh9y+8dOWiUn2Qv/d8+EPOn9ZMtrhrUVCs+hvBa10knKeZwGGiJbUecueHOyubr1iq tdE72hNRzkG6WR/4BKXlXEA37HKfnkzUjb7yM+vafcQjwBNuZo2g35BKXX6vQsSAzF50 GEcdNiuAqYyU058nRcxtIUyl6oLfatXzllyI1p1Ipx7q2ds+je8swIVCAic/dIU68cJo dxcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=+cjrkZ98QKsDzpzmc47sIt4SrJWySQ26BIXGlS919FI=; b=yrk9e6tIJJtg8TDAfVVTHDjg0WJaHO5rO8gQEPzmbDya/y1zwyUC7PPzX14yPgqjzR OIyE3GbSEHqMsV3a0+BKM47MxlsYO+9ZEjVMV010BF3VVRrtiIifRX6VSMAlNizwMXw2 Fq9VMglQ5ep5B3Hz0AzYYNJcTh++X6gJ7+ms5RR9m9qwurnkw7VJdaenSWI+eObMEmxM 593KSilX1aI3lvVy2W9i9OyvJb1wL7yRkbgVvIRSdItObkp9ZVY6rVKESb4xxW4NgBIE naQ2kjgxTl5eKB3MV9gY78zrWEIL6hynJY4N2bPPaKA1/UoAZIjEw7SHVgDIzps6XwpL g1cA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h7si1847756edt.553.2021.03.04.04.46.26; Thu, 04 Mar 2021 04:46:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237662AbhCDAAX (ORCPT + 99 others); Wed, 3 Mar 2021 19:00:23 -0500 Received: from vmi485042.contaboserver.net ([161.97.139.209]:38422 "EHLO gentwo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1387965AbhCCUE0 (ORCPT ); Wed, 3 Mar 2021 15:04:26 -0500 Received: by gentwo.de (Postfix, from userid 1001) id 17718B007D1; Wed, 3 Mar 2021 20:55:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id 0F843B005D8; Wed, 3 Mar 2021 20:55:49 +0100 (CET) Date: Wed, 3 Mar 2021 20:55:48 +0100 (CET) From: Christoph Lameter To: Matthew Wilcox cc: Xunlei Pang , Vlastimil Babka , Wen Yang , Roman Gushchin , Pekka Enberg , Konstantin Khlebnikov , David Rientjes , linux-kernel@vger.kernel.org, "linux-mm@kvack.org" Subject: Re: [PATCH v2 3/3] mm/slub: Use percpu partial free counter In-Reply-To: <20210303193038.GE2723601@casper.infradead.org> Message-ID: References: <1597061872-58724-1-git-send-email-xlpang@linux.alibaba.com> <1597061872-58724-4-git-send-email-xlpang@linux.alibaba.com> <20210303142612.GC2723601@casper.infradead.org> <20210303193038.GE2723601@casper.infradead.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Mar 2021, Matthew Wilcox wrote: > > Can this be allocated in an interrupt context? > > > > And I am not sure how local_t relates to that? Percpu counters can be used > > in an interrupt context without the overhead of the address calculations > > that are required by a local_t. > > As I understand the patch, this counts the number of partially free slabs. > So if we start to free an object from a completely full slab in process > context, as "load x, add one to x, store x" and take an interrupt > between loading x and adding one to x, that interrupt handler might > free a different object from another completely full slab. that would > also load the same x, add one to it and store x, but then the process > context would add one to the old x, overwriting the updated value from > interrupt context. this_cpu operations are "atomic" vs. preemption but on some platforms not vs interrupts. That could be an issue in kmem_cache_free(). This would need a modification to the relevant this_cpu ops so that interrupts are disabled on those platforms. Like this_cpu_inc_irq() or so? > it's not the likeliest of races, and i don't know how important it is > that these counters remain accurate. but using a local_t instead of > a percpu long would fix the problem. i don't know why you think that > a local_t needs "address calculations". perhaps you've misremembered > what a local_t is? local_t does not include the address arithmetic that the this_cpu operation can implicitly perform on x86 f.e. with an segment register or maybe another register on another platform thereby avoiding the need to disable preemption or interrupts. Therefore a manual calculation of the target address for a local_t operation needs to be done beforehand which usually means disabling interrupts and/or preemption for the code segment. Otherwise we may end up on a different processor due to scheduler or other interruptions and use the percpu counter value of a different processor which could be racy.