Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2423061ybl; Thu, 9 Jan 2020 12:29:20 -0800 (PST) X-Google-Smtp-Source: APXvYqwz8Hykw/8smOb8C+YhZ7sgyZGo53cpfU7aQKrPtnlR16bgf2p6hw8+q7agppH9WsMQ1IGJ X-Received: by 2002:a05:6830:4d5:: with SMTP id s21mr9652649otd.294.1578601759885; Thu, 09 Jan 2020 12:29:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578601759; cv=none; d=google.com; s=arc-20160816; b=JGzod/A15eMfJKxLSylOjbDLNdZYBfr30fp+k48WY4gHkpzegwGbI9yo2hhH+swYjY TVl3y7qq+hkGBw3aJtZ20qrxmJsyg7dRKTSOcUfdX4JnFdrwHPl4xmeNKcan+nc6e2M2 tkL1pUuoTPLoQulgXcEOOoBFuepWhtF4WN1gpbY9J4mzNU5qQcmuCfQnfgd3303JUffR PLjKIzkKG3jixt/WqugYOIoXibDu6r+VBrVjOcHQSJkznv4Jxt/IlKcv+Ph7xM1ypYPW uLmWMfqDmow0gHHHJpZTohJUvUrtSBJU06nZejkn5ZsYBDjBZ7TCoN4l7cuPFVosvWKj w8UA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:message-id:subject:cc:to:from:date; bh=7TSQYriTg5VG77/nJFT1SS7TPZ9nHjd3X7ZCVmo9DAQ=; b=xgfUrZnhj4zaQC6go2EurHKqCQ0eQX4SbNBvd1pF3y6zr8zeMM7ZRdCTZkZxgGDeBD EzLkr/9BQsqBcdRBBER0aAUEdHVtIsr+oXGOwg8FnF9ZlG2DuuJgOHONcKSLXsDkeDcw N5hVmHTM08C4VJo5jra6eo7ublJh+Cjsu+dmnsBdY8fDYgA5WxYqIcdcIX7icIeqUOcK d9cFqK/nfRyVB3DSnfpBXmNgTy05BpkFPkCdS3HWkX28Gzxe73Khy3tLurdFHbKOBxT/ d0/znAgl7xFYj+5JRnmJ8SxHbeXWOPyz5pRiksrYaTrUnciQMBCzZuY1MsXGRqJa8qm6 EYpg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t74si4130015oih.155.2020.01.09.12.28.57; Thu, 09 Jan 2020 12:29:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387753AbgAIQi3 (ORCPT + 99 others); Thu, 9 Jan 2020 11:38:29 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:54101 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387752AbgAIQi3 (ORCPT ); Thu, 9 Jan 2020 11:38:29 -0500 Received: from callcc.thunk.org (guestnat-104-133-0-111.corp.google.com [104.133.0.111] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 009Gc2nI015609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jan 2020 11:38:03 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 16BD94207DF; Thu, 9 Jan 2020 11:38:02 -0500 (EST) Date: Thu, 9 Jan 2020 11:38:02 -0500 From: "Theodore Y. Ts'o" To: Ritesh Harjani , Jan Kara Cc: Xiaoguang Wang , Ext4 Developers List , joseph.qi@linux.alibaba.com, Liu Bo Subject: Re: Discussion: is it time to remove dioread_nolock? Message-ID: <20200109163802.GA33929@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200109123427.GD22232@quack2.suse.cz> <20200109092142.E90E2A4062@b06wcsmtp001.portsmouth.uk.ibm.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Jan 09, 2020 at 02:51:42PM +0530, Ritesh Harjani wrote: > > Dbench was slightly impacted; I didn't see any real differences with > > compilebench or postmark. dioread_nolock did improve fio with > > sequential reads; which is interesting, since I would have expected > > IIUC, this Seq. read numbers are with --direct=1 & bs=2MB & ioengine=libaio, > correct? > So essentially it will do a DIO AIO sequential read. Correct. >In this run, was encryption or fsverity enabled? >If yes then in that case I see that ext4_dio_supported() will return >false and it will fallback to bufferedRead. No, there was no encryption or fsverity enabled. These runs were pure stock ext4, with no additional features or mount options other than the defaults --- and in the case of the dioread_nolock runs, just the dioread_nolock mount option was added. On Thu, Jan 09, 2020 at 01:34:27PM +0100, Jan Kara wrote: > > > > I started running some performance runs last night, and the > > Thanks for the numbers! What is the difference between 'default-1' and > 'default-2' configurations (and similarly between dioread_nolock-1 and -2 > configurations)? default-1 and default-2 are two runs using the default mke2fs and ext4 mount options. So 4k blocks, no encryption, no fs-verity, delayed allocation, and the kernel version includes the inode locking patches, but not the dio overwrite patch (that's for the next merge window, and this was 5.5-rc3). dioread-1 and dioread-2 are two runs with the exact same file system, the same VM and PD. The file system would have been slightly aged since I did not recreate the file system between each of the four runs. File system aging might be explain some of the differences; the other possbility is some kind of differences caused by differing amounts of CPU and network availability on the host system (which could have affected the Persistent Disk performance). GCE does try to provide enough isolation and throttling however, and the outliers are generally in the positive, not negative direction, so I don't *think* it's caused by host loading issues, but I can't 100% rule it out. One of the things PTS does do is to increase the number of runs until the standard deviation drops below some percentage (4 or 5%, I think). In particular, I've noticed that fsmark sometimes require quite a few runs before the results fall within that criteria. So it's quite possible that the fs-mark variations might have been luck. That's one of the reasons why I performed multiple runs, was to try to see if that was what was going on. > > dioread_nolock did improve fio with > > sequential reads; which is interesting, since I would have expected > > with the inode_lock improvements, there shouldn't have been any > > difference. So that may be a bit of wierdness that we should try to > > understand. > > Yes, this is indeed strange. I don't see anything the DIO read path where > dioread_nolock would actually still matter. The fio runs do tend to be pretty stable, and generally only require PTS to performe 3 runs to get stable results. That's why the variations and differences found when doing runs with and without dioread_nolock were *very* unexpected. - Ted