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;
Date:   Thu, 14 Oct 2021 05:51:13 +0100
From:   Christoph Hellwig <hch@infradead.org>
To:     Pavel Begunkov <asml.silence@gmail.com>
Cc:     Christoph Hellwig <hch@infradead.org>,
        Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] block: don't hide inode from block_device users
Message-ID: <YWe3QZD+g8MSoCtT@infradead.org>
References: <cover.1634115360.git.asml.silence@gmail.com>
 <2b8c84834a304871d78f91d4ebe153fac2192fd5.1634115360.git.asml.silence@gmail.com>
 <YWb6VgEjEZFexiV0@infradead.org>
 <194577df-0402-6e3c-3534-af289b5494e0@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <194577df-0402-6e3c-3534-af289b5494e0@gmail.com>
Precedence: bulk

On Wed, Oct 13, 2021 at 07:44:20PM +0100, Pavel Begunkov wrote:
> Mildly hot in io_uring w/o fixed files, but that's not peak perf,
> but would also be great to get rid of bdev->bd_inode dereference,
> e.g. lots of in fops.c.
> 
> Are you going to just hid the dereference in helpers or kill it
> with some offseting magic?

The only real hot path uses I found is the size (which you and Jens
already seem to have moved to use something out of the inode for the
fast path),  and maybe the blkbits for which we could do the same.

So basically the idea is to not touch the inode in the hot path,
and use accessors helpers in bdev.c that could do the offsetof trick.