Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 16 Jan 2023 02:52:41 -0800
From:   Breno Leitao <leitao@debian.org>
To:     Gabriel Krisman Bertazi <krisman@suse.de>
Cc:     asml.silence@gmail.com, dylany@meta.com, axboe@kernel.dk,
        io-uring@vger.kernel.org, leit@fb.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] io_uring: Split io_issue_def struct
Message-ID: <Y8UseW5sTqu72M2U@gmail.com>
References: <20230112144411.2624698-1-leitao@debian.org>
 <20230112144411.2624698-2-leitao@debian.org>
 <87v8lbcwz9.fsf@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87v8lbcwz9.fsf@suse.de>
Precedence: bulk

On Thu, Jan 12, 2023 at 05:35:22PM -0300, Gabriel Krisman Bertazi wrote:
> Breno Leitao <leitao@debian.org> writes:
> 
> > This patch removes some "cold" fields from `struct io_issue_def`.
> >
> > The plan is to keep only highly used fields into `struct io_issue_def`, so,
> > it may be hot in the cache. The hot fields are basically all the bitfields
> > and the callback functions for .issue and .prep.
> >
> > The other less frequently used fields are now located in a secondary and
> > cold struct, called `io_cold_def`.
> >
> > This is the size for the structs:
> >
> > Before: io_issue_def = 56 bytes
> > After: io_issue_def = 24 bytes; io_cold_def = 40 bytes
> 
> Does this change have an observable impact in run time? Did it show
> a significant decrease of dcache misses?

I haven't tested it. I expect it might be hard to came up with such test.

A possible test might be running io_uring heavy tests, while adding
enough memory pressure. Doing this in two different instant (A/B test),
might be a unpredicable and the error deviation might hide the benefit.