Received: by 10.213.65.68 with SMTP id h4csp661663imn; Fri, 16 Mar 2018 15:01:07 -0700 (PDT) X-Google-Smtp-Source: AG47ELv75ub69uE51Rd/Aw/UM8eGat1o78GXNeeHqUuk+k1MoOt8GZgut9A+otSk+QZDXwrilr3U X-Received: by 10.101.89.65 with SMTP id g1mr2675732pgu.185.1521237666966; Fri, 16 Mar 2018 15:01:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521237666; cv=none; d=google.com; s=arc-20160816; b=aoqNsfUKGxn4NfO1SkC/A1aE9mJ4b08xuR0xLeJIj8L5kLBB2jbNJ9PAg8VwZst3EB jf2gtxXkHGvIReUTFtVx4SZ0XnU/SmkusGlZAWmVj6owv4S5AU3TQy68UYfoRRVofwkb JNn6rj0Hp2PJDsRsNFer8TvXVzRv3VS3qe2++SuC6+4a7rxD7imCTNyb1h8PLt/3gX+g /mCOtIhWcFEwvVw0K+XXhRBemM57y150DHvgSUKq0CWhMxPLLUzLGSKid+5w071vxMsL ryWQnuBuqO54VSAeCBrSbUZWhZqgV9k1Wgn1xDIUrlCwolUg7q6dvcZin07MDoBwsiSG b0Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=nKKdxbGV1mle5x1BjCH7AWz7F3TzZRjlFWkAJRUNEsc=; b=tPbWye5AEMC54BuE1RADh7SFhL8A7l54T5ANfih/fQndMkR7NER7kG/2LHfjftjGAS Q2DudikDHID5K94nqFpuPY0l6VmiC7IQZC4VQvQc/BA6FI5xRwz4oL9dR/XpOTpKNA6U gP9WWqFcgBKchWCS6louqVsmOrUeUKJKrcD2AQeNlt/DBsiOKZAtHQHtuWjY8y177FRk QY+ZfMRUmDAgFBydSiWUwGU3HeWgfuD2vpy7B2b2xIlV3XMJeKlGbJ+h5fgFYiPfW2LR TGA8HGbXZS5cwGmEhHGTezPvfVz3y2r/2CRNkLZw+DwPmyG9DqoIgEXaVojwttLuyPEm Imrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v32-v6si7011958plb.301.2018.03.16.15.00.51; Fri, 16 Mar 2018 15:01:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbeCPV7p (ORCPT + 99 others); Fri, 16 Mar 2018 17:59:45 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:54924 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750915AbeCPV7o (ORCPT ); Fri, 16 Mar 2018 17:59:44 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id C2F4BDEB; Fri, 16 Mar 2018 21:59:43 +0000 (UTC) Date: Fri, 16 Mar 2018 14:59:42 -0700 From: Andrew Morton To: Wei Wang Cc: Wei Wang , gregkh@linuxfoundation.org, Todd Poynor , Dan Williams , Michal Hocko , "Kirill A. Shutemov" , Jan Kara , =?ISO-8859-1?Q?J=E9r=F4me?= Glisse , Hugh Dickins , Matthew Wilcox , Ingo Molnar , Sherry Cheung , "Oliver O'Halloran" , Andrey Ryabinin , Huang Ying , Dennis Zhou , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: add config for readahead window Message-Id: <20180316145942.9e2d353ed10041fbac42e5a3@linux-foundation.org> In-Reply-To: References: <20180316182512.118361-1-wvw@google.com> <20180316143306.dd98055a170497e9535cc176@linux-foundation.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 16 Mar 2018 21:51:48 +0000 Wei Wang wrote: > On Fri, Mar 16, 2018, 14:33 Andrew Morton wrote: > > > On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang wrote: > > > > > Change VM_MAX_READAHEAD value from the default 128KB to a configurable > > > value. This will allow the readahead window to grow to a maximum size > > > bigger than 128KB during boot, which could benefit to sequential read > > > throughput and thus boot performance. > > > > You can presently run ioctl(BLKRASET) against the block device? > > > > Yeah we are doing tuning in userland after init. But this is something we > thought could help in very early stage. > "thought" and "could" are rather weak! Some impressive performance numbers for real-world setups would help such a patch along.