Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp191336pxa; Fri, 21 Aug 2020 04:59:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3qBBJKIbZ1eAl2EFTVbWcsUMrZegdDZrReZOSN1EsoZo+x/2dnsrb7IWB+gfy+g1qC9PX X-Received: by 2002:a17:906:c7d3:: with SMTP id dc19mr2399025ejb.495.1598011178531; Fri, 21 Aug 2020 04:59:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598011178; cv=none; d=google.com; s=arc-20160816; b=bnMQpgrlkw+/89fCX+kHg0BBijE/QqyPz5P6/+R4Y1fPyxtueKuL/rRzHlhVMDpSe0 /gC3yr/nIf2viUzrbjYhFgIqIkRbWFlBjmg3ZFI6ghmrCeM02bKLvlqg7Vg2NzLkjq94 5fWGG6p5pLzQHbvMV8e7qiRvNNmVwm5Fx1P3G1cilMSrxDMPO6N9gYHXmlnGE+Iabh2R IAoLYd2QVqwmoz1/38PxrGAmkdT2ssqezESP7EcdvH/QmxJqQXyRnHbdR0GUa/u+YXiR K3oUe4ZzkNiPoiDSnAAvq9DQgEpyEPSjZaaFbsVKfst0CDt4Jqdvtrh2fr5UwDAjcF3E NLyw== 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:references:message-id:subject:cc:to:from:date :dkim-signature; bh=3FksEgmPr7vqNMfiZSMm66QbIR2tGNR9y3WIbd3p5w0=; b=wXzrf3OiGm3TrMKfozF9w7MjbaO/Ou+6Lov/9fdrauWZZnjrK2mBxt51nc7Agkmg8o OR1OaWYvleJMogbqVYRjlhkE3MMAK2QZaOdkybgA/nUmtlnEiesEhh1hnnhnuIz4Fvw3 G0bW6YEf3lV9kCqXeICFOV1Cf5Rh6PjmwxE7UyEAPLMRxUlMY0sBbYyQ2cRq9F9ItEz2 K+kBx04MhD/3bHjwnr3GtAiFX5COOakRiHKLdFW/2l3y4qXAUksY9AqTQoYIuCY6sLBA nIKZXm2whtu7YelEqClRdsPbHHL4Q7GvyxVR/msvzn9lSmtLZN3gWuKu1Hd1enes3JNd bueQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=hWycvsSS; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g29si450618edj.492.2020.08.21.04.59.14; Fri, 21 Aug 2020 04:59:38 -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=fail header.i=@infradead.org header.s=casper.20170209 header.b=hWycvsSS; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727931AbgHUL6F (ORCPT + 99 others); Fri, 21 Aug 2020 07:58:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727106AbgHUL6E (ORCPT ); Fri, 21 Aug 2020 07:58:04 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53587C061385 for ; Fri, 21 Aug 2020 04:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=3FksEgmPr7vqNMfiZSMm66QbIR2tGNR9y3WIbd3p5w0=; b=hWycvsSSENpNlsX6AfzbZx5Cej LUs8aJdAspH6c6AdiyqHpmzxRWT8fUx3a6uIeN5hNWToWZqjGprV/3ZR8rVx9lnuK17szKiwSqdzQ ou+kYQ76LnUlNgFICJr1LHqF4a6YD2xLO2zHJmcF8STK5f0Ox2/yzSkrrEKTDdSg6WA7QFH21pjYK rUUIVYykNHzc1IQxBzEiB2SAeudothLRy/Bj/SjdonMqzDiXZMWO9OkUqXqUYMePG/6WibYToCrhV KUogg6lRjBlkaeQGavjN0q+N0Qfsmjquy+RT1uRfB0uUP+5o6WsRZunV+3/QVy97WuQKufPhyA0DV xTgCpUVA==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k95g0-00086n-Rm; Fri, 21 Aug 2020 11:57:44 +0000 Date: Fri, 21 Aug 2020 12:57:44 +0100 From: Matthew Wilcox To: Zhaoyang Huang Cc: Andrew Morton , Minchan Kim , Zhaoyang Huang , "open list:MEMORY MANAGEMENT" , LKML , chunyan.zhang@unisoc.com, Baolin Wang Subject: Re: [PATCH v2] mm : sync ra->ra_pages with bdi->ra_pages Message-ID: <20200821115744.GP17456@casper.infradead.org> References: <1598001864-6123-1-git-send-email-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 21, 2020 at 05:31:52PM +0800, Zhaoyang Huang wrote: > This patch has been verified on an android system and reduces 15% of > UNITERRUPTIBLE_SLEEP_BLOCKIO which was used to be caused by wrong > ra->ra_pages. Wait, what? Readahead doesn't sleep on the pages it's requesting. Unless ... your file access pattern is random, so you end up submitting a readahead I/O that's bigger than needed, so takes longer for the page you actually wanted to be returned. I know we have the LOTSAMISS logic, but that's not really enough. OK, assuming this problem is really about sync mmap (ie executables), this makes a bit more sense. I think the real problem is here: ra->start = max_t(long, 0, offset - ra->ra_pages / 2); ra->size = ra->ra_pages; ra->async_size = ra->ra_pages / 4; ra_submit(ra, mapping, file); which actually skips all the logic we have in ondemand_readahead() for adjusting the readahead size. Ugh, this is a mess. I think a quick fix to your problem will be just replacing ra->ra_pages with bdi->ra_pages in do_sync_mmap_readahead() and leaving ra->ra_pages alone everywhere else. We need a smarter readahead algorithm for mmap'ed files, and I don't have time to work on it right now. So let's stick to the same dumb algorithm, but make it responsive to bdi ra_pages being reset.