From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D7030A21; Fri, 16 Feb 2024 00:37:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708043869; cv=none; b=a0F0mt1W04lorHIU8xeOcRSM7he30RAwwE8Rbju1S+W/0MgY3rlfbkPa15k/JsViw2hoRHLeSKpYauLj04JIY+TdzRVpYygAtSQDuJlzQoZR3bZIzG73HMxxCBts+nRmoKpBFPFrmqZ3GW+L20bsqpszZWs64zVzo4h6yl2Z7g4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708043869; c=relaxed/simple; bh=YpMrmy2WNszZOajuF+8g9MSTe1WwFvsOvg16QLWytFw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sNmOvAoJvr5pwPRGZ09iJyJBAzV2mVvBPipXBsvr6rgaSqlIwXuI9G43dSHPdyBgh6KZYpJKNdr+g98TkoKbqivgIoP1TBCGp/EDVyg0eoSWYKiK892MFUJwUqDGkcV5IaeI+n9HkmEapG6az5FdppmGRwItmNaUQWT3zJc5/0w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED6A9C433F1; Fri, 16 Feb 2024 00:37:40 +0000 (UTC) Date: Thu, 15 Feb 2024 19:39:15 -0500 From: Steven Rostedt To: Kent Overstreet Cc: Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , akpm@linux-foundation.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Subject: Re: [PATCH v3 31/35] lib: add memory allocations report in show_mem() Message-ID: <20240215193915.2d457718@gandalf.local.home> In-Reply-To: References: <320cd134-b767-4f29-869b-d219793ba8a1@suse.cz> <20240215180742.34470209@gandalf.local.home> <20240215192141.03421b85@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 15 Feb 2024 19:32:38 -0500 Kent Overstreet wrote: > > But where are the benchmarks that are not micro-benchmarks. How much > > overhead does this cause to those? Is it in the noise, or is it noticeable? > > Microbenchmarks are how we magnify the effect of a change like this to > the most we'll ever see. Barring cache effects, it'll be in the noise. > > Cache effects are a concern here because we're now touching task_struct > in the allocation fast path; that is where the > "compiled-in-but-turned-off" overhead comes from, because we can't add > static keys for that code without doubling the amount of icache > footprint, and I don't think that would be a great tradeoff. > > So: if your code has fastpath allocations where the hot part of > task_struct isn't in cache, then this will be noticeable overhead to > you, otherwise it won't be. All nice, but where are the benchmarks? This looks like it will have an affect on cache and you can talk all you want about how it will not be an issue, but without real world benchmarks, it's meaningless. Numbers talk. -- Steve