From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCHv2 0/6] dm-zoned: improve cache performance Date: Wed, 20 May 2020 14:53:34 -0400 Message-ID: <20200520185334.GA4926@redhat.com> References: <20200519081424.103318-1-hare@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com Content-Disposition: inline To: Damien Le Moal Cc: "dm-devel@redhat.com" List-Id: dm-devel.ids On Tue, May 19 2020 at 6:36pm -0400, Damien Le Moal 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? > Mike, > > With the NVMe io_opt fix patch applied, the alignment warning for the target > limits is gone. OK Thanks, Mike