All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Shaun Tancheff <shaun@tancheff.com>,
	linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>, Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@lst.de>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Damien Le Moal <damien.lemoal@hgst.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Sagi Grimberg <sagig@mellanox.com>,
	Mike Christie <mchristi@redhat.com>,
	Ming Lei <ming.lei@canonical.com>,
	Josh Bingaman <josh.bingaman@seagate.com>,
	Shaun Tancheff <shaun.tancheff@seagate.com>
Subject: Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors
Date: Mon, 22 Aug 2016 09:11:58 +0200	[thread overview]
Message-ID: <ad5c983d-ae7c-bd5b-edef-b56552c3038b@suse.de> (raw)
In-Reply-To: <20160822043402.8855-3-shaun@tancheff.com>

On 08/22/2016 06:34 AM, Shaun Tancheff wrote:
> Currently the RB-Tree zone cache is fast and flexible. It does
> use a rather largish amount of ram. This model reduces the ram
> required from 120 bytes per zone to 16 bytes per zone with a
> moderate transformation of the blk_zone_lookup() api.
> 
> This model is predicated on the belief that most variations
> on zoned media will follow a pattern of using collections of same
> sized zones on a single device. Similar to the pattern of erase
> blocks on flash devices being progressivly larger 16K, 64K, ...
> 
> The goal is to be able to build a descriptor which is both memory
> efficient, performant, and flexible.
> 
> Signed-off-by: Shaun Tancheff <shaun.tancheff@seagate.com>
> ---
>  block/blk-core.c       |    2 +-
>  block/blk-sysfs.c      |   31 +-
>  block/blk-zoned.c      |  103 +++--
>  drivers/scsi/sd.c      |    5 +-
>  drivers/scsi/sd.h      |    4 +-
>  drivers/scsi/sd_zbc.c  | 1025 +++++++++++++++++++++++++++---------------------
>  include/linux/blkdev.h |   82 +++-
>  7 files changed, 716 insertions(+), 536 deletions(-)
> 
Have you measure the performance impact here?
The main idea behind using an RB-tree is that each single element will
fit in the CPU cache; using an array will prevent that.
So we will increase the number of cache flushes, and most likely a
performance penalty, too.
Hence I'd rather like to see a performance measurement here before going
down that road.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N�rnberg
GF: F. Imend�rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG N�rnberg)

WARNING: multiple messages have this Message-ID (diff)
From: Hannes Reinecke <hare@suse.de>
To: Shaun Tancheff <shaun@tancheff.com>,
	linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>, Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@lst.de>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Damien Le Moal <damien.lemoal@hgst.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Sagi Grimberg <sagig@mellanox.com>,
	Mike Christie <mchristi@redhat.com>,
	Ming Lei <ming.lei@canonical.com>,
	Josh Bingaman <josh.bingaman@seagate.com>,
	Shaun Tancheff <shaun.tancheff@seagate.com>
Subject: Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors
Date: Mon, 22 Aug 2016 09:11:58 +0200	[thread overview]
Message-ID: <ad5c983d-ae7c-bd5b-edef-b56552c3038b@suse.de> (raw)
In-Reply-To: <20160822043402.8855-3-shaun@tancheff.com>

On 08/22/2016 06:34 AM, Shaun Tancheff wrote:
> Currently the RB-Tree zone cache is fast and flexible. It does
> use a rather largish amount of ram. This model reduces the ram
> required from 120 bytes per zone to 16 bytes per zone with a
> moderate transformation of the blk_zone_lookup() api.
> 
> This model is predicated on the belief that most variations
> on zoned media will follow a pattern of using collections of same
> sized zones on a single device. Similar to the pattern of erase
> blocks on flash devices being progressivly larger 16K, 64K, ...
> 
> The goal is to be able to build a descriptor which is both memory
> efficient, performant, and flexible.
> 
> Signed-off-by: Shaun Tancheff <shaun.tancheff@seagate.com>
> ---
>  block/blk-core.c       |    2 +-
>  block/blk-sysfs.c      |   31 +-
>  block/blk-zoned.c      |  103 +++--
>  drivers/scsi/sd.c      |    5 +-
>  drivers/scsi/sd.h      |    4 +-
>  drivers/scsi/sd_zbc.c  | 1025 +++++++++++++++++++++++++++---------------------
>  include/linux/blkdev.h |   82 +++-
>  7 files changed, 716 insertions(+), 536 deletions(-)
> 
Have you measure the performance impact here?
The main idea behind using an RB-tree is that each single element will
fit in the CPU cache; using an array will prevent that.
So we will increase the number of cache flushes, and most likely a
performance penalty, too.
Hence I'd rather like to see a performance measurement here before going
down that road.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

  parent reply	other threads:[~2016-08-22  7:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-22  4:34 [PATCH 0/2] Change zone cache format to use less memory Shaun Tancheff
2016-08-22  4:34 ` [PATCH 1/2] Move ZBC core setup to sd_zbc Shaun Tancheff
2016-08-22  4:34 ` [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors Shaun Tancheff
2016-08-22  5:25   ` Shaun Tancheff
2016-08-22  7:11   ` Hannes Reinecke [this message]
2016-08-22  7:11     ` Hannes Reinecke
2016-08-22 15:43     ` Shaun Tancheff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad5c983d-ae7c-bd5b-edef-b56552c3038b@suse.de \
    --to=hare@suse.de \
    --cc=axboe@fb.com \
    --cc=axboe@kernel.dk \
    --cc=damien.lemoal@hgst.com \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=josh.bingaman@seagate.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mchristi@redhat.com \
    --cc=ming.lei@canonical.com \
    --cc=sagig@mellanox.com \
    --cc=shaun.tancheff@seagate.com \
    --cc=shaun@tancheff.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.