From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756224AbcHVPn5 (ORCPT ); Mon, 22 Aug 2016 11:43:57 -0400 Received: from mx0b-00003501.pphosted.com ([67.231.152.68]:21687 "EHLO mx0a-000cda01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756206AbcHVPnx (ORCPT ); Mon, 22 Aug 2016 11:43:53 -0400 Authentication-Results: seagate.com; dkim=pass header.s="google" header.d=seagate.com MIME-Version: 1.0 In-Reply-To: References: <20160822043402.8855-1-shaun@tancheff.com> <20160822043402.8855-3-shaun@tancheff.com> From: Shaun Tancheff Date: Mon, 22 Aug 2016 10:43:29 -0500 Message-ID: Subject: Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors To: Hannes Reinecke Cc: Shaun Tancheff , linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, LKML , Jens Axboe , Jens Axboe , Christoph Hellwig , "James E . J . Bottomley" , "Martin K . Petersen" , Damien Le Moal , Dan Williams , Sagi Grimberg , Mike Christie , Ming Lei , Josh Bingaman Content-Type: text/plain; charset=UTF-8 X-Proofpoint-PolicyRoute: Outbound X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-22_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608220163 X-Proofpoint-Spam-Policy: Default Domain Policy Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 22, 2016 at 2:11 AM, Hannes Reinecke 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 >> --- >> 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