lkml.org 
[lkml]   [2011]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@linux.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@linux.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


\
 
 \ /
  Last update: 2011-08-18 21:45    [W:0.243 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site