linux-kernel - Re: [PATCH 10/11] VFS: Cache request_queue in struct block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110818194245.GJ15413@redhat.com>
Date:	Thu, 18 Aug 2011 15:42:45 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	hch@...radead.org, Andi Kleen <ak@...ux.intel.com>,
	Jens Axboe <jaxboe@...ionio.com>
Subject: Re: [PATCH 10/11] VFS: Cache request_queue in struct block_device

On Mon, Aug 01, 2011 at 09:38:12PM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@...ux.intel.com>
> 
> This makes it possible to get from the inode to the request_queue
> with one less cache miss. Used in followon optimization.
> 
> The livetime of the pointer is the same as the gendisk.
> 
> This assumes that the queue will always stay the same in the
> gendisk while it's visible to block_devices. I think that's safe correct?
> 
> Signed-off-by: Andi Kleen <ak@...ux.intel.com>
> ---
>  fs/block_dev.c     |    3 +++
>  include/linux/fs.h |    2 ++
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index f55aad4..5e07536 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -1110,6 +1110,7 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, int for_part)
>  	mutex_lock_nested(&bdev->bd_mutex, for_part);
>  	if (!bdev->bd_openers) {
>  		bdev->bd_disk = disk;
> +		bdev->bd_queue = disk->queue;

I am really not sure how good a idea it is to stash away another pointer
in bdev (bdev->queue), just because we don't want to dereference a pointer
(bdev->bd_disk->queue). 

Personally I think it is not a very good idea as if we start following
everywhere in the code, it will make things more complicated.

Is the performance gain because of this one less dereference really 
substantial.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/