Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2578824ybh; Mon, 9 Mar 2020 08:40:39 -0700 (PDT) X-Google-Smtp-Source: ADFU+vv4nURfNNboIk/AlGKd0wg4igPBaMBeL/rzaw4qFGGc6ufwCMg238xPBJ/BtPibO7/RupfD X-Received: by 2002:a05:6808:f:: with SMTP id u15mr11356621oic.124.1583768439315; Mon, 09 Mar 2020 08:40:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583768439; cv=none; d=google.com; s=arc-20160816; b=SLH27IMdjlf/AMFGK6iQB9LcEMKgiqChumOE0aWc+LYTcZpBNrKZOvQyrFNncufJjv EC8DoA64sdX6RUxNi68AYjr7I4amXybONKwu7fav7vZMPhtDKxw9sacTk3yE/N2r5o2/ sRm2FTVK9EZPvYO1oURRC/MTaZ7jtg9N8kJ0/ZW9z0J4SQGGG+BxB/wYhPitwbjKEjTV 6MEscUVTJkVlKPqyJPiqrbuGUKp49/rsgviHWHoAlUvjLekHkHd3/xwkzZjyEFNuoewV MDcK8q4mcCa1vrRXSTfHdyaasgFMfVRNQfpN3LU/yMNrQ93Y3i1L7nM2k6MhIYOuZGf6 hCtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=K6/r8kvFDu7nEapSZzFLnvOMNaUeDl0u4C70+oHAP1Y=; b=l3DnD9cDlWUZ+KxbpQKCkcvO9A87pm/F6dem6FWPKQe2c8fEg7BmOVlnN3srez0MhT i8PJOAZXF97B5k2Ftr3hzkPRnIhky2cVuJ8J2WRM07ZdcaoQnDIoWbAwXxO7ChxUo7DT 0V4OX6jHBFMfxzr0mJMkRbzOiR4uQquwnkUpD8TC7WJfEfNk+o0ekGBAUICuErFWH/pt p/xKt4TPg+m/LfN2YiHFV775eon1+Li/JOZtu+o5kT7n9A2TgSAXPty4BKSjukA8OwtW qC26i40vURN0aIv+dRhhr7HZa1ZD0e2C3ytW/P76pQpE4IWjBNIFD1QdDYSOscJUlgGo 5Liw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v137si4020446oif.170.2020.03.09.08.40.26; Mon, 09 Mar 2020 08:40:39 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727095AbgCIPid (ORCPT + 99 others); Mon, 9 Mar 2020 11:38:33 -0400 Received: from mga07.intel.com ([134.134.136.100]:36195 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726899AbgCIPid (ORCPT ); Mon, 9 Mar 2020 11:38:33 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2020 08:38:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,533,1574150400"; d="scan'208";a="440958564" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.21]) by fmsmga005.fm.intel.com with ESMTP; 09 Mar 2020 08:38:31 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id 764EA301BCC; Mon, 9 Mar 2020 08:38:31 -0700 (PDT) Date: Mon, 9 Mar 2020 08:38:31 -0700 From: Andi Kleen To: Michal Hocko Cc: "Kirill A. Shutemov" , Cannon Matthews , Mike Kravetz , Andrew Morton , Matthew Wilcox , David Rientjes , Greg Thelen , Salman Qazi , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] mm: clear 1G pages with streaming stores on x86 Message-ID: <20200309153831.GK1454533@tassilo.jf.intel.com> References: <20200307010353.172991-1-cannonmatthews@google.com> <20200309000820.f37opzmppm67g6et@box> <20200309090630.GC8447@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200309090630.GC8447@dhcp22.suse.cz> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Gigantic huge pages are a bit different. They are much less dynamic from > the usage POV in my experience. Micro-optimizations for the first access > tends to not matter at all as it is usually pre-allocation scenario. On > the other hand, speeding up the initialization sounds like a good thing > in general. It will be a single time benefit but if the additional code > is not hard to maintain then I would be inclined to take it even with > "artificial" numbers state above. There really shouldn't be other downsides > except for the code maintenance, right? There's a cautious tale of the old crappy RAID5 XOR assembler functions which were optimized a long time ago for the Pentium1, and stayed around, even though the compiler could actually do a better job. String instructions are constantly improving in performance (Broadwell is very old at this point) Most likely over time (and maybe even today on newer CPUs) you would need much more sophisticated unrolled MOVNTI variants (or maybe even AVX-*) to be competitive. The best clear functions may also be different for different CPU generations. Using the string instructions has the advantage that all of this is abstracted from the kernel. -Andi