Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1467363 > unrolled thread

[PATCH 0/2] Change zone cache format to use less memory

Started byShaun Tancheff <shaun@tancheff.com>
First post2016-08-22 06:40 +0200
Last post2016-08-22 17:50 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/2] Change zone cache format to use less memory Shaun Tancheff <shaun@tancheff.com> - 2016-08-22 06:40 +0200
    Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of  descriptors Hannes Reinecke <hare@suse.de> - 2016-08-22 09:20 +0200
      Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors Shaun Tancheff <shaun.tancheff@seagate.com> - 2016-08-22 17:50 +0200

#1467363 — [PATCH 0/2] Change zone cache format to use less memory

FromShaun Tancheff <shaun@tancheff.com>
Date2016-08-22 06:40 +0200
Subject[PATCH 0/2] Change zone cache format to use less memory
Message-ID<s8PbH-1um-3@gated-at.bofh.it>
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.

Shaun Tancheff (2):
  Move ZBC core setup to sd_zbc
  Migrate zone cache from RB-Tree to arrays of descriptors

 block/blk-core.c       |    2 +-
 block/blk-sysfs.c      |   31 +-
 block/blk-zoned.c      |  103 +++--
 drivers/scsi/sd.c      |   66 +--
 drivers/scsi/sd.h      |   20 +-
 drivers/scsi/sd_zbc.c  | 1037 +++++++++++++++++++++++++++++-------------------
 include/linux/blkdev.h |   82 +++-
 7 files changed, 759 insertions(+), 582 deletions(-)

-- 
2.9.3

[toc] | [next] | [standalone]


#1467415 — Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors

FromHannes Reinecke <hare@suse.de>
Date2016-08-22 09:20 +0200
SubjectRe: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors
Message-ID<s8RGx-3cc-1@gated-at.bofh.it>
In reply to#1467363
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)

[toc] | [prev] | [next] | [standalone]


#1467743 — Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors

FromShaun Tancheff <shaun.tancheff@seagate.com>
Date2016-08-22 17:50 +0200
SubjectRe: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors
Message-ID<s8ZE5-89K-11@gated-at.bofh.it>
In reply to#1467415
On Mon, Aug 22, 2016 at 2:11 AM, Hannes Reinecke <hare@suse.de> wrote:
> 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?

As far as actual hardware (HostAware) I am seeing the same
I/O performance. I suspect its just that below 100k iops the
zone cache just isn't a bottleneck.

> 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.

I think it will have to be a simulated benchmark, if that's okay.

Of course I'm open to suggestions if there is something you have in mind.
-- 
Regards,
Shaun Tancheff

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web