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 55E9CC4338F for ; Sat, 7 Aug 2021 21:24:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5452161042 for ; Sat, 7 Aug 2021 21:23:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5452161042 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 2E24F8D0001; Sat, 7 Aug 2021 17:23:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 292C26B0071; Sat, 7 Aug 2021 17:23:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A8328D0001; Sat, 7 Aug 2021 17:23:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id F2D336B006C for ; Sat, 7 Aug 2021 17:23:57 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 90E1F202E3 for ; Sat, 7 Aug 2021 21:23:57 +0000 (UTC) X-FDA: 78449562114.09.2613227 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id D0B1D50461A3 for ; Sat, 7 Aug 2021 21:23:55 +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=aA5HS3VKpHetp3gEzc9iEc7bj1aIHq24Bb+xq3Es5LU=; b=ZANN2lpGFk3nRvYarK5XIJERCS +NWy2JNCxNY8Xi5VPTrnA35PD3MBwN1VX1/TbeotRkLWlnE9uGyLrEOAms1Uj+oQrn7pFH2b//W9q pCO1iHwG8qo4Kh5SstGa3R6JtvKOXW3mZhNjtWW0tRJ3VHP4nvelHc3CxVpboE5tVqK+94MPyo6iz ARzIkO/WcEkruk+OoNSXvfG5pdzyj7PFkOg3nOXp4xU+m3lQavDI7OaUtAsAtj0Ml8WlJX00dNnm6 OKXvflohBcntsuD/TJCGb0oivj3nXcoHSORrezQhpl4j1tJOTk6eWTKmlTibiU4nXfYOdVQWwjxZk mu9nrYOA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mCTmj-009Smd-Tl; Sat, 07 Aug 2021 21:23:17 +0000 Date: Sat, 7 Aug 2021 22:23:13 +0100 From: Matthew Wilcox To: Hugh Dickins Cc: Zi Yan , Vlastimil Babka , David Hildenbrand , linux-mm@kvack.org, "Kirill A . Shutemov" , Mike Kravetz , Michal Hocko , John Hubbard , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 00/15] Make MAX_ORDER adjustable as a kernel boot time parameter. Message-ID: References: <20210805190253.2795604-1-zi.yan@sent.com> <0d374eed-cc52-a656-b338-1156782bdf7e@suse.cz> <6ae6cd92-3ff4-7ed3-b337-a4dfe33da1c@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D0B1D50461A3 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ZANN2lpG; dmarc=none; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: e5cyum53s41fe4i7cdstj4mtj7531qt1 X-HE-Tag: 1628371435-58293 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 Sat, Aug 07, 2021 at 02:10:55AM +0100, Matthew Wilcox wrote: > This hasn't been helped by the scarce number of 1GB TLB entries in Intel > CPUs until very recently (and even those are hard to come by today). Minor correction to this. I just fixed x86info to work on my Core i7-1165G7 (Tiger Lake, launched about a year ago) and discovered it has: L1 Store Only TLB: 1GB/4MB/2MB/4KB pages, fully associative, 16 entries L1 Load Only TLB: 1GB pages, fully associative, 8 entries L2 Unified TLB: 1GB/4KB pages, 8-way associative, 1024 entries My prior laptop (i7-7500U, Kaby Lake, 2016) has only 4x 1GB TLB entries at the L1 level, and no support for L2 1GB pages. So this speaks to Intel finally taking performance of 1GB TLB entries seriously. Perhaps more seriously than they need to for a laptop with 16GB of memory! There are Xeon-W versions of this CPU, so I imagine that there are versions which can support 1TB or more memory. I still think that 1GB pages are too big for anything but specialist use cases, but those do exist.