From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 775ECC433E1 for ; Tue, 25 Aug 2020 01:26:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1565F2072D for ; Tue, 25 Aug 2020 01:25:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tEp/OEWL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1565F2072D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7C14F90001D; Mon, 24 Aug 2020 21:25:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74AC18D0002; Mon, 24 Aug 2020 21:25:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6139590001D; Mon, 24 Aug 2020 21:25:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id 494FE8D0002 for ; Mon, 24 Aug 2020 21:25:59 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 09B991EF2 for ; Tue, 25 Aug 2020 01:25:59 +0000 (UTC) X-FDA: 77187349638.20.taste19_0c0058027057 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id D39FD180C07A3 for ; Tue, 25 Aug 2020 01:25:58 +0000 (UTC) X-HE-Tag: taste19_0c0058027057 X-Filterd-Recvd-Size: 4564 Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 25 Aug 2020 01:25:58 +0000 (UTC) Received: by mail-io1-f68.google.com with SMTP id w20so7489359iom.1 for ; Mon, 24 Aug 2020 18:25:58 -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=/BQ53bR9yzL5LCkQfVs+ALLFFuHnjhrGR7al0c4QWdM=; b=tEp/OEWL/eQB1zCKQeNoB5C1Gl7GMu1z02dU3GW78P8V9VwSwgXvgSVvQEA/zpLwca 9LB7yPkk9kfrQ3T2YALjtlFFQCCNJPlxfTIGkBNM4RWVKYAkoBenhNi+d6iqMyil/9L4 HagHEQGJf4blTAFb6VtuMF4h8Y8NJSKf9J4YAvdMMpzYPfFfSf/qM2O7Z+aAn9hYM1Af S2aDHrTZRu+jxrdKqdRNDuGjgZu+qt9prvyLOg5c3dnlJTsMzpOVYMmWwV41AdzqzA3q 36/Q8ygp6O67P3xRn8CWhv3PigokqiJiKKCh31MXzFu195rf17UFxzV483RIjgxUhfPY 9+XQ== 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=/BQ53bR9yzL5LCkQfVs+ALLFFuHnjhrGR7al0c4QWdM=; b=YagPespKilrlBKcLbtrlvqo8otgQjvNSrCBkw++na8ogZZsaxkJ2Obt8AjlZscxZ8v LUpRjykSbfedSBJ/KaC5Ivnr3/qVC4mps+jTP6XG42cSbnLF/5x+9/H/bO3MKynFye4i Nw20MAmoCxR7q8BLVS9mCeNeLTHtVC8zQXKLifB1aH4EJaxlkx23qnU0ohZx7oDB5xYr gUvOXJuspZI5EH/pY3L7ThIxRKqMjten8R1UVvS1wQZ5Y7Cch5zLMRZrp2G09I1ujkWY Yvg++Rve5xAHJaGWDooH0nI3gcIRx0veo9tE9okWX5/y8UKej2F17yHkQaNFdEQ/mCwa Cz2w== X-Gm-Message-State: AOAM531sF+wfum+2hP/tUJ/DBblMD9Ydi0usTTBF0rk7aUhJZCLrjWfa sd9g8fWuncD8Dpomo5B0ptAfGlFHB/ADehJdnZY= X-Google-Smtp-Source: ABdhPJw2xfStQ7PbjYeqOx6pCmz+i4QPf/M0ygzrEuKOnEsaqhaU71n3HeAHsNbaN9Ky+owM0M/ybADrcHNtON4O+fs= X-Received: by 2002:a05:6638:298:: with SMTP id c24mr8439577jaq.20.1598318757876; Mon, 24 Aug 2020 18:25:57 -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: Tue, 25 Aug 2020 09:25:46 +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" X-Rspamd-Queue-Id: D39FD180C07A3 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. > > 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 can't just sync ra->ra_pages with bdi->ra_pages as eio and fadvise will shrink or turbo it, that is why I introduce seq_read_fact in this commit > 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.