[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAP_z_CgoG73txYYVgyCcVvrCbw+Jc5F=ud2DOXG5vwoVgUukHA@mail.gmail.com>
Date: Wed, 13 Aug 2025 10:00:40 -0700
From: Blake Jones <blakejones@...gle.com>
To: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>,
Josh Don <joshdon@...gle.com>, Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Reorder some fields in struct rq.
Hi Madadi,
Thanks so much for reviewing this, and I'm glad to hear that the
change seemed to work well for you.
On Wed, Aug 13, 2025 at 12:30 AM Madadi Vineeth Reddy
<vineethr@...ux.ibm.com> wrote:
> Also ran ebizzy, which doesn’t seem to be impacted. I think it would be good
> to run a set of standard benchmarks like schbench, ebizzy, hackbench, and
> stress-ng, along with a real-life workload, to ensure there’s no negative
> impact. I saw that hackbench was tried, but including those numbers would
> be helpful.
I agree that it would be interesting to have such a set of benchmarks
- and also, I'm not sure what they should be. Part of why I mentioned
my experiment with hackbench is that I'd seen it cited several times
as a standard scheduling benchmark, and my conclusion from running it
and profiling it was that I wouldn't recommend including it in a
canonical set of scheduling benchmarks. I don't have my actual numbers
from running it, but my recollection was that any delta in performance
that it showed was well within the margin of error of the test.
I did run this change on a fraction of the Google server fleet, as an
experiment along with a few other related data structure tweaks, and
saw a meaningful improvement in application performance. But I only
got results for the experiment as a whole, so I can't be sure how much
of the improvement was due to this change vs. the others.
Blake
> Reviewed-by: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
> Tested-by: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
Powered by blists - more mailing lists