All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCHv2 0/6] dm-zoned: improve cache performance
Date: Wed, 20 May 2020 23:59:22 +0000	[thread overview]
Message-ID: <BY5PR04MB69005CEAD9EC02ABFE2943C2E7B60@BY5PR04MB6900.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20200520185334.GA4926@redhat.com

On 2020/05/21 3:53, Mike Snitzer wrote:
> On Tue, May 19 2020 at  6:36pm -0400,
> Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> 
>> On 2020/05/19 17:14, Hannes Reinecke wrote:
>>> Hi all,
>>>
>>> here's an update to dm-zoned to separate out cache zones.
>>> In the update to metadata version 2 the regular drive was split
>>> in emulated zones, which were handled just like 'normal' random
>>> write zones.
>>> This causes a performance drop once these emulated zones have
>>> been mapped, as typicall the random zones from the zoned drive
>>> will perform noticeably slower than those from the regular drive.
>>> (After all, that was kinda the idea of using a regular disk in
>>> the first place ...)
>>>
>>> So in this patchset I've introduced a separate 'cache' zone type,
>>> allowing us to differentiate between emulated and real zones.
>>> With that we can switch the allocation mode to use only cache
>>> zones, and use random zones similar to sequential write zones.
>>> That avoids the performance issue noted above.
>>>
>>> I've also found that the sequential write zones perform noticeably
>>> better on writes (which is all we're caching anyway), so I've
>>> added another patch switching the allocation routine from preferring
>>> sequential write zones for reclaim.
>>>
>>> This patchset also contains some minor fixes like remving an unused
>>> variable etc.
>>>
>>> As usual, comments and reviews are welcome.
>>
>> I ran this overnight with no problems. Throughput results attached.
>> Reclaim seems to be a little too aggressive as it triggers very early. But we
>> can tune that later if really needed: the combination of ext4 writing all over
>> the place and the faster cache zones on SSD may simply result in a percentage of
>> free cache zones becoming low very quickly, in which case, reclaim is working
>> exactly as expected :)
> 
> I've staged this series for 5.8 in linux-next
> 
> Just to make sure no regressions due to all the metadata2 changes: Did
> you happen to verify all worked as expected without using an extra
> drive?

Yes, I did.  Single and dual drive both work fine with v2 metadata.
I will retest the case of a V1 format using V2 code to be extra sure.

> 
>> Mike,
>>
>> With the NVMe io_opt fix patch applied, the alignment warning for the target
>> limits is gone.
> 
> OK
> 
> Thanks,
> Mike
> 
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2020-05-20 23:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  8:14 [PATCHv2 0/6] dm-zoned: improve cache performance Hannes Reinecke
2020-05-19  8:14 ` [PATCH 1/6] dm-zoned: return NULL if dmz_get_zone_for_reclaim() fails to find a zone Hannes Reinecke
2020-05-19 22:15   ` Damien Le Moal
2020-05-19  8:14 ` [PATCH 2/6] dm-zoned: separate random and cache zones Hannes Reinecke
2020-05-19 22:23   ` Damien Le Moal
2020-05-19  8:14 ` [PATCH 3/6] dm-zoned: reclaim random zones when idle Hannes Reinecke
2020-05-19 22:26   ` Damien Le Moal
2020-05-19  8:14 ` [PATCH 4/6] dm-zoned: start reclaim with sequential zones Hannes Reinecke
2020-05-19 22:27   ` Damien Le Moal
2020-05-19  8:14 ` [PATCH 5/6] dm-zoned: terminate reclaim on congestion Hannes Reinecke
2020-05-19 22:29   ` Damien Le Moal
2020-05-19  8:14 ` [PATCH 6/6] dm-zoned: remove unused variable in dmz_do_reclaim() Hannes Reinecke
2020-05-19 22:29   ` Damien Le Moal
2020-05-19 17:36 ` [PATCHv2 0/6] dm-zoned: improve cache performance Mike Snitzer
2020-05-19 22:36 ` Damien Le Moal
2020-05-20 18:53   ` Mike Snitzer
2020-05-20 23:59     ` Damien Le Moal [this message]
2020-05-21  7:56     ` Damien Le Moal

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=BY5PR04MB69005CEAD9EC02ABFE2943C2E7B60@BY5PR04MB6900.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=dm-devel@redhat.com \
    --cc=snitzer@redhat.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.