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 E175817991; Fri, 16 Feb 2024 01:11:12 +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=1708045873; cv=none; b=uWpHVoY4jRHcWz5DQf9bWm4ZtslKyYuSPHqOusEzweptyQIKri2FxjYGmH+NAriFTim8SXwG5VM5xuNKbvhRPrnf08HbNKk1hkDqf7vp8RnzMoGbOUb7eD3o/hmjn8h+F9K+HTlXVvZmFFQlOrXdqpLpFYuVHqDoJFuaSDtgbPc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708045873; c=relaxed/simple; bh=oztQecXN6o6vKFvgQ7Cw0FO8kgeZTEB225WAZJbSFVc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=d2DYsxpCOnHXhOKOv5BbVWqN4iDTUYiwbiIUaKzPBzbbklhKpOcot0MqFJ70KACSSrXupx7OpYD5StI96JjM2nUWFy5/TBqbUDLE5NS9dFysp38yGo95cVjekkZIxmppTqs19P3b/qJrLNlD++9hav529QCWBogXD8+UsCVeXg8= 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 3C847C433F1; Fri, 16 Feb 2024 01:11:05 +0000 (UTC) Date: Thu, 15 Feb 2024 20:12:39 -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: <20240215201239.30ea2ca8@gandalf.local.home> In-Reply-To: References: <320cd134-b767-4f29-869b-d219793ba8a1@suse.cz> <20240215180742.34470209@gandalf.local.home> <20240215192141.03421b85@gandalf.local.home> <20240215193915.2d457718@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-doc@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:50:24 -0500 Kent Overstreet wrote: > > 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, you're being demanding. We provided sufficient benchmarks to show > the overhead is low enough for production, and then I gave you a > detailed breakdown of where our overhead is and where it'll show up. I > think that's reasonable. It's not unreasonable or demanding to ask for benchmarks. You showed only micro-benchmarks that do not show how cache misses may affect the system. Honestly, it sounds like you did run other benchmarks and didn't like the results and are fighting to not have to produce them. Really, how hard is it? There's lots of benchmarks you can run, like hackbench, stress-ng, dbench. Why is this so difficult for you? -- Steve