Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp49690ybt; Tue, 30 Jun 2020 14:34:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzd7gIGEWVly9PoTD+/GLI/7H5r/R/FbDMqkBLwqMsH/+OmY3RgaYPZbkoz5qR8BHu44eqU X-Received: by 2002:a50:e04e:: with SMTP id g14mr20688170edl.352.1593552368422; Tue, 30 Jun 2020 14:26:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593552368; cv=none; d=google.com; s=arc-20160816; b=RtyOWICtYnCAKu/HF+KHQlqTRN9/gY31GCn7EHWs0tu9yuGYzSa9EM3NZGZwplLZWH t3Ym70bVDKO8DIqR5uZRdehAXVXPXha2x9DF3a4cMoilO+SYLIjDbejLdcgu4/iAr0PT wZa0LAEYrOo477WrBhuQqkeh5hPGGwXxi3RvzCcFr1PbezIXtkO5C9X95NfgA/Y9CEhS 3Mj6lB1s0kbEIrx1y6P2zyt6eB02RDRE2acTPRDHy8BFi0orxKYiNjJGHdReJo+tZoXi xa9+M3Zo1ZpeVn4NGDVK5769bk8ddkpy8UINVr1j4l4Ij+u2DhQyqwWGP9rOQg166ENG xzsQ== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=2xmefk2RteGTnbCye5bI/kRpYMG9zcRY+jbKjm732i0=; b=zouDBUR005fGTDevGY0lH4zPkH+FPxULFJ7ggasVBA9xJA+ZU8Ub6KkLOXHO62r/eJ nMlUx7iCjA6ng2/0PtPla4Y6kaa8mk/Ihj1I9eW4aX8Rr0ymcsNwP/VPXVtsQrT20OLH Yaq9oBvDL1TvQcOcBzbYXH6jBalSPC8YiLzD2l9xKS+MoVmPvqYN+PYA8uEUgS3qVLLh 4jRm5zupO47TChW5GqQ8aIbzecfMqSKtdvLxiG4VvancBkbMV7Z/Y46aQr2jwInuPe92 b+2o1lMw7QBiuWaGXQvPke+tus2MIuBWF+OUfGeBpIPUcbHn6cJQXbM4QtM4hfCnJchP /YZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oWxbFf0d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v14si2509694eje.123.2020.06.30.14.25.44; Tue, 30 Jun 2020 14:26:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oWxbFf0d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729637AbgF3Unv (ORCPT + 99 others); Tue, 30 Jun 2020 16:43:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728340AbgF3Unv (ORCPT ); Tue, 30 Jun 2020 16:43:51 -0400 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E30B2C061755 for ; Tue, 30 Jun 2020 13:43:50 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id y18so8962983plr.4 for ; Tue, 30 Jun 2020 13:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=2xmefk2RteGTnbCye5bI/kRpYMG9zcRY+jbKjm732i0=; b=oWxbFf0dWEbKgf1ijqpkDLiaARpUgLO8Yms473N+ftU2hDK0S7Sg+q1MAZbJrbqDwl jRk2EiiRBLa7Fpj/uVMGQYoaEVbAfTXeZIPTdL/EzyFcaSvbMX1/WphEUbAfY55+YDPH wW4P7EuEl7iVQRhv6g3EadgIvwbFLfBY7ChCox/euQHzbuVk3hFGuXFCte+KLZZvZJd3 hByPirK0qMX9hPHHHtvniYveX8u+MFuE96iCRhrnGQUAqXP8jfUASfvJdIjePM9Uplb4 sU7nkYBxfpxH20++z8JHxiWwovrmTmEMXjPOZa7ywL45+LN29uFh+jEvjZ8zt54IL30V A5rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=2xmefk2RteGTnbCye5bI/kRpYMG9zcRY+jbKjm732i0=; b=gMChKrrWC5yuv/sWqiFvEFsH+R9yspQ7GEo8Eay0c/GNzKI72ppx45iPg34Q2u5kkI xlgViVyB8SJiTnWWbXFNS2o7dH8BjNlUUo2cwnPHFsF2lcXo1M07pJiI7b4r0PMn5sY1 ZjbQWDKfjph+7juylhrjp+FW2SAaPV4NMMxroFIzKmjJLU77zuxkUmbwKT3/P1+/kSn5 cJFJa3xkXmJImItqmWX/WtFHqfV/wiR9LsQ0oJowqcLCyRBnW30IIOhTuGlHFRTaBMsM F6uw66e/IDQrTTSrUvPqMYAS0vN496i/SST2QSXK1tMAwSFWVFhhUeEUwyMpnJtrdEgZ PD4w== X-Gm-Message-State: AOAM532vMyr3etUCS6dlAeIgmIKZn40VAfzgMIvQY8NNkwpYi3I9XDHo zOVKcHD6GdQeQga9EjCa23U= X-Received: by 2002:a17:90a:fd12:: with SMTP id cv18mr17159212pjb.66.1593549830267; Tue, 30 Jun 2020 13:43:50 -0700 (PDT) Received: from ubuntu-s3-xlarge-x86 ([2604:1380:1000:7a00::1]) by smtp.gmail.com with ESMTPSA id ia13sm3047342pjb.42.2020.06.30.13.43.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2020 13:43:49 -0700 (PDT) Date: Tue, 30 Jun 2020 13:43:48 -0700 From: Nathan Chancellor To: Jaegeuk Kim Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com Subject: Re: [f2fs-dev] [PATCH v3] f2fs: avoid readahead race condition Message-ID: <20200630204348.GA2504307@ubuntu-s3-xlarge-x86> References: <20200624012148.180050-1-jaegeuk@kernel.org> <20200629150323.GA3293033@google.com> <20200629202720.GA230664@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200629202720.GA230664@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 29, 2020 at 01:27:20PM -0700, Jaegeuk Kim wrote: > If two readahead threads having same offset enter in readpages, every read > IOs are split and issued to the disk which giving lower bandwidth. > > This patch tries to avoid redundant readahead calls. > > Signed-off-by: Jaegeuk Kim > --- > v3: > - use READ|WRITE_ONCE > v2: > - add missing code to bypass read > > fs/f2fs/data.c | 18 ++++++++++++++++++ > fs/f2fs/f2fs.h | 1 + > fs/f2fs/super.c | 2 ++ > 3 files changed, 21 insertions(+) > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index 995cf78b23c5e..360b4c9080d97 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -2296,6 +2296,7 @@ static int f2fs_mpage_readpages(struct inode *inode, > unsigned nr_pages = rac ? readahead_count(rac) : 1; > unsigned max_nr_pages = nr_pages; > int ret = 0; > + bool drop_ra = false; > > map.m_pblk = 0; > map.m_lblk = 0; > @@ -2306,10 +2307,24 @@ static int f2fs_mpage_readpages(struct inode *inode, > map.m_seg_type = NO_CHECK_TYPE; > map.m_may_create = false; > > + /* > + * Two readahead threads for same address range can cause race condition > + * which fragments sequential read IOs. So let's avoid each other. > + */ > + if (rac && readahead_count(rac)) { > + if (READ_ONCE(F2FS_I(inode)->ra_offset) == readahead_index(rac)) > + drop_ra = true; > + else > + WRITE_ONCE(F2FS_I(inode)->ra_offset, > + readahead_index(rac)); > + } > + > for (; nr_pages; nr_pages--) { > if (rac) { > page = readahead_page(rac); > prefetchw(&page->flags); > + if (drop_ra) > + goto next_page; When CONFIG_F2FS_FS_COMPRESSION is not set (i.e. x86_64 defconfig + CONFIG_F2FS_FS=y): $ make -skj"$(nproc)" O=out distclean defconfig fs/f2fs/data.o ../fs/f2fs/data.c: In function ‘f2fs_mpage_readpages’: ../fs/f2fs/data.c:2327:5: error: label ‘next_page’ used but not defined 2327 | goto next_page; | ^~~~ ... Cheers, Nathan