Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp682516pxa; Fri, 21 Aug 2020 18:51:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzhNoF3dtA4SI8mCbdsSHenuR/Q1O7g0BP0UnfZVk4VTNOdsGvZR2ozmvecvTfx/WscmJ++ X-Received: by 2002:a17:906:b88b:: with SMTP id hb11mr2114123ejb.59.1598061099046; Fri, 21 Aug 2020 18:51:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598061099; cv=none; d=google.com; s=arc-20160816; b=bRhxwAQeM3nYm7C211jl/qvuELaA7xVW/eJQCAjZmzm0N8kegG+CSp1t7qkEOVFz0n oAZnDU4/dTUS5k4w8ahv9DowhnHWbEvr6SC/89P2JppcCaUVoEzTUSt6ntMhZL7HRaKP y36o5bdjka7jmKsVDItTzNQooR7+j//uo8jpMi+jdOA0V/Z9sInPIn0zBw3/dVw2nN5Z +mjAN56dco1ccgGoufA9z4DD3PS83IPDxBcRy17vao8kWmu3ejtjWRSPRCH1q0NLjP1G QOjOzlK7JcP2tocAMIzERgicw6Tjayvh1g/P0Ct+NZV6oapkf4NOZpLZo9KtVfblJ0xo yxgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=dHF10WW8TJA1FQjc9LfnwaeL+wDisEs0yu/R1D6jHbg=; b=wU/+rptzhEhXBFepYzLwTVXxt9ZAA73o2nwqHIRyLB1MNDTNEBo4RJLSz3Y6iHLFOS wlms3diLiPuACuYoSubmf9xvkNanZMPvnQJIYm/LvK97J1L3lMIYHzki6e0gIin24T8Y fx6jXaBiZqdWGyYoEMJS63tq4N7EAxMLbXoxPmjX7GLKmZZXTLFiUW0g7YVTzbaC2lRH 6cKkKzXlT+hkLvLTvL0Ti148nNdDUUhvmxsYUyLXFIgBAwLB2TkuWsnFMiFb8fWOBz3B pcj9YqsYtPhSqUh23ty9xFXO25yu0VOYmwnbAPnmw/NM43avpw5YeagCZTdtUAzjqqzU Zs1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ua8TDynK; 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 q6si2403232edg.496.2020.08.21.18.51.15; Fri, 21 Aug 2020 18:51:39 -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=Ua8TDynK; 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 S1726519AbgHVBrF (ORCPT + 99 others); Fri, 21 Aug 2020 21:47:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725935AbgHVBrC (ORCPT ); Fri, 21 Aug 2020 21:47:02 -0400 Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98DB3C061573 for ; Fri, 21 Aug 2020 18:47:02 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id 4so3527202ion.13 for ; Fri, 21 Aug 2020 18:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dHF10WW8TJA1FQjc9LfnwaeL+wDisEs0yu/R1D6jHbg=; b=Ua8TDynKR0J3DZT3d+BCDJiRjd+RbJ0G8rSRCmUTr4oGXrovvNgWL6r6/bvMqgBEs5 nRPAjd6SCJBzUacgYzce0zKaFCG94gjSd2SKIz3+PQGCfmWsiZikViw2fe88co7PCLNj vmtZLqnQ/hDeeLU5/Kr9m8+ahw/COiwkFHcZmcZlSYOTjGMmi77+KsBXnJyMm6gbsfsX jPWJdvsn2lXB/yF8MRI3BS3kKJ2pXWqORxzvmWd7CNuONYYxCYsQZVuNPQZg6IknTcPI 5/8sj654xaI9/c5FLZKfRvqFgycyvw1Ac3M9vhjXt9f9+w0zrx9aldlr49EejUWnUEiM BPNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dHF10WW8TJA1FQjc9LfnwaeL+wDisEs0yu/R1D6jHbg=; b=LpzizpHhuynWTbF7OT/S94AU1ZXBmqW0Nxwk/g/wFPtWpPXFO+U6SAhLh8n+ci1QR5 8bNNxetO6JieSjOhm7Y/1Pz1vH5GdQ3k4sE0J7zqy+VKtANL+rq4gNS2mEIDyMFwp93n SVFgjuq3btphLJzhdPjxRYovdREZqpQsuId29Jb8o3vRq5At3p6A8pttELRVyRyUfwsc AC3V2ZTwlkllH1KbO8gdg6V1e1lPwOQdqH0o8DYV71cs/823TobEyft4iHC+oiPbuA4H gGzMKEEJ4bfVTbqmfVxTPptIcZ5SfhUu4t9d1vXSRAzGdAL+aSPdwUYd6nvYDGjmpZaC 9JYg== X-Gm-Message-State: AOAM533pnZOvrAuwLIZ+dYNNF4AT2U/Vq+E3A/ccujtT/c8BGrknexXO XRzRFiaCPSRFi+/+h9cbFnJvzBVtE63KhlMFd1Y= X-Received: by 2002:a02:c9d5:: with SMTP id c21mr4885337jap.72.1598060821862; Fri, 21 Aug 2020 18:47:01 -0700 (PDT) MIME-Version: 1.0 References: <1598001864-6123-1-git-send-email-zhaoyang.huang@unisoc.com> <20200821115744.GP17456@casper.infradead.org> In-Reply-To: <20200821115744.GP17456@casper.infradead.org> From: Zhaoyang Huang Date: Sat, 22 Aug 2020 09:46:50 +0800 Message-ID: Subject: Re: [PATCH v2] mm : sync ra->ra_pages with bdi->ra_pages To: Matthew Wilcox Cc: Andrew Morton , Minchan Kim , Zhaoyang Huang , "open list:MEMORY MANAGEMENT" , LKML , chunyan.zhang@unisoc.com, Baolin Wang Content-Type: text/plain; charset="UTF-8" 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 7:57 PM Matthew Wilcox wrote: > > 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. actually, async read even if hitting the marker will also introduce huge mount of read by wrong ra->ra_pages, which will be used as req_size for ondemand_readahead. > > 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.