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_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 61DBEC433E0 for ; Fri, 12 Mar 2021 15:10:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0E44A64DF0 for ; Fri, 12 Mar 2021 15:10:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E44A64DF0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A32286B006E; Fri, 12 Mar 2021 10:10:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A08DC6B0070; Fri, 12 Mar 2021 10:10:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8ADA16B0073; Fri, 12 Mar 2021 10:10:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 6EC056B006E for ; Fri, 12 Mar 2021 10:10:52 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2D86837E7 for ; Fri, 12 Mar 2021 15:10:52 +0000 (UTC) X-FDA: 77911559544.04.4640D93 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 89C63E007A62 for ; Fri, 12 Mar 2021 15:10:40 +0000 (UTC) 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=PGicOecPTl82O+7IKA07blzMMq5LKKLTqGu6MRSyaSY=; b=Wug9nQ81BRxnzSIOt7fbCTQild cafzlxjkiw5dVoXgkCIKFukV6WYtZhr6HlbGnjnPFvrctWDCWSNbIOsXPg+0qkOKZ8a7aS1OffmxQ KW2eLbB+lddTJ6aTYiKXUffO6QAI8wbFE4/1pML2749rrxd9p+DJYJ174htipjl7V4a2mDBTkq1kT jC46EyvUwnS7FJQnDFpLCeEwi5jZEl29P469M/jyYD7pqhESrZUJz6URb6Bupd6mRrL0jeEtL9qB7 aHqsj35XEb51oD/PMP+ICUny6ZB5VqKfpbn5x3pS2vPDYSbeMnWp/YWucWNy7ESv4sqgPlq8CwDwJ Um2NDW1w==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lKjQn-00Ax1J-2I; Fri, 12 Mar 2021 15:10:27 +0000 Date: Fri, 12 Mar 2021 15:10:25 +0000 From: Matthew Wilcox To: Mel Gorman Cc: Andrew Morton , Chuck Lever , Jesper Dangaard Brouer , Christoph Hellwig , LKML , Linux-Net , Linux-MM , Linux-NFS Subject: Re: [PATCH 0/5] Introduce a bulk order-0 page allocator with two in-tree users Message-ID: <20210312151025.GB2577561@casper.infradead.org> References: <20210310104618.22750-1-mgorman@techsingularity.net> <20210310154704.9389055d0be891a0c3549cc2@linux-foundation.org> <20210311084827.GS3697@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210311084827.GS3697@techsingularity.net> X-Stat-Signature: q7x68pee885bjfc1dwh81ndbagjoswuh X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 89C63E007A62 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615561840-225577 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 Thu, Mar 11, 2021 at 08:48:27AM +0000, Mel Gorman wrote: > I don't have that information unfortunately. It's a chicken and egg > problem because without the API, there is no point creating new users. > For example, fault around or readahead could potentially batch pages > but whether it is actually noticable when page zeroing has to happen > is a completely different story. It's a similar story for SLUB, we know > lower order allocations hurt some microbenchmarks like hackbench-sockets > but have not quantified what happens if SLUB batch allocates pages when > high-order allocations fail. I'm planning on reducing overhead in the readahead path by allocating higher-order pages rather than by allocating a batch of order-0 pages. With the old ->readpages interface, it would have made sense to allocate a batch of pages, but with the new ->readahead interface, we put the pages into the page cache for the filesystem, so it doesn't make as much sense any more. Right now, measuring performance in the readahead path is hard because we end up contending against kswapd that's trying to evict all the clean pages that we earlier readahead into this same file. Could avoid that by having N files, each about half the size of memory, but then we restart the readahead algorithm for each file ... I feel like the real solution for that is to do a GFP_NOWAIT allocation, then try to evict earlier pages for the same file we're working on so that kswapd doesn't get woken up if we're just streaming a read through a gargantuan file. But I should probably talk to Johannes first.