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=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 4E93DC10F25 for ; Wed, 11 Mar 2020 03:35:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F3CE920578 for ; Wed, 11 Mar 2020 03:35:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QveIo4Xi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3CE920578 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=alum.mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8CCBF6B0003; Tue, 10 Mar 2020 23:35:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87DD06B0006; Tue, 10 Mar 2020 23:35:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 793866B0007; Tue, 10 Mar 2020 23:35:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 61B776B0003 for ; Tue, 10 Mar 2020 23:35:58 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2042B5DEB for ; Wed, 11 Mar 2020 03:35:58 +0000 (UTC) X-FDA: 76581667596.12.month37_6e45f7e16505c X-HE-Tag: month37_6e45f7e16505c X-Filterd-Recvd-Size: 6859 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 11 Mar 2020 03:35:57 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id e11so780866qkg.9 for ; Tue, 10 Mar 2020 20:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=wCWT2o5DFKKbBLuoSAVQOpMO8+LfC0dfYXlp5Cfyx5Q=; b=QveIo4XiPZyXhpsCHpYBHBIaDmxvs9lx/j4w1Zlq1KgieD+UXs0M8K332X10crh0WW rZDoxfAV8uOfh/CSthrLcWP82zySmkq0ZzljKC9hKbtF8SvLyhHda7MPLiYW3JAKRlPs Mxd3e/vj0/qGIXkJkZMgL5YxBl7oDPBBErf/Q8LoQshpbvUQdbwRlQYBt143XIsehgcx z0plpjm3N7wWr7yZLuelfn4chkqudfklm7C04wAbAahgxD4f+zkGUcvY++GpAMtGiSsk 067xIhxvA6G1JuXsEPCRpkqOSUtRJgBxdjcBNRVpMxevwIN46g4vpLjJaXmL4gMeNOgd Ih4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=wCWT2o5DFKKbBLuoSAVQOpMO8+LfC0dfYXlp5Cfyx5Q=; b=MT2RdzbJiE1SY2Nr68sFti/qS8mQrzOgJ50Q9w4PoENOYR+/YmyDogmJaFm5tNeCYC RaDgNJ4N9PmLuAF55t9vmFU+0VvG56KtFT1VrT52Qr+C8nDCs4TTFTegMOipqsIesU/0 1A9a4naq/iSQe3rjT0bfPExrruxGmBXJalkMGYO68XwpMoXaaH5NGZ0+h4a+D1dzMkiZ IPhyH7ak4vO0iGLRUCSDXJ9WboQbcmKl4YnotTigrtr/vZUWKFmNjKVNfoHgcj2kFQ94 rJJ9ZfGBXki3cQZ+uq7JseuFeNP8FagN1qnklIOPNxIZO7ONs3r/QfZMwvUOHEkLSzL/ Z+ZA== X-Gm-Message-State: ANhLgQ1yReevzI+cBM76y+3SKRSjkBnsO7V0DNm4BUQr4djGQ1hFlLzX ZstSpYvFOwz3gxXWMFgHs/w= X-Google-Smtp-Source: ADFU+vsC+ly4UL0+Oz7izjR+zZLM45UVgl4Jty5phpX2+9h59lw4KRivmGBCNPmXKI0V/m50TadHqw== X-Received: by 2002:a37:b041:: with SMTP id z62mr894840qke.487.1583897756906; Tue, 10 Mar 2020 20:35:56 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id w2sm25034621qto.73.2020.03.10.20.35.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 20:35:56 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Tue, 10 Mar 2020 23:35:54 -0400 To: "Kirill A. Shutemov" Cc: Cannon Matthews , Matthew Wilcox , Andi Kleen , Michal Hocko , Mike Kravetz , Andrew Morton , 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: <20200311033552.GA3657254@rani.riverdale.lan> References: <20200307010353.172991-1-cannonmatthews@google.com> <20200309000820.f37opzmppm67g6et@box> <20200309090630.GC8447@dhcp22.suse.cz> <20200309153831.GK1454533@tassilo.jf.intel.com> <20200309183704.GA1573@bombadil.infradead.org> <20200311005447.jkpsaghrpk3c4rwu@box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200311005447.jkpsaghrpk3c4rwu@box> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Wed, Mar 11, 2020 at 03:54:47AM +0300, Kirill A. Shutemov wrote: > On Tue, Mar 10, 2020 at 05:21:30PM -0700, Cannon Matthews wrote: > > On Mon, Mar 9, 2020 at 11:37 AM Matthew Wilcox wrote: > > > > > > On Mon, Mar 09, 2020 at 08:38:31AM -0700, Andi Kleen wrote: > > > > > 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. > > > > > > Presumably you have access to current and maybe even some unreleased > > > CPUs ... I mean, he's posted the patches, so you can test this hypothesis. > > > > I don't have the data at hand, but could reproduce it if strongly > > desired, but I've also tested this on skylake and cascade lake, and > > we've had success running with this for a while now. > > > > When developing this originally, I tested all of this compared with > > AVX-* instructions as well as the string ops, they all seemed to be > > functionally equivalent, and all were beat out by this MOVNTI thing for > > large regions of 1G pages. > > > > There is probably room to further optimize the MOVNTI stuff with better > > loop unrolling or optimizations, if anyone has specific suggestions I'm > > happy to try to incorporate them, but this has shown to be effective as > > written so far, and I think I lack that assembly expertise to micro > > optimize further on my own. > > Andi's point is that string instructions might be a better bet in a long > run. You may win something with MOVNTI on current CPUs, but it may become > a burden on newer microarchitectures when string instructions improves. > Nobody realistically would re-validate if MOVNTI microoptimazation still > make sense for every new microarchitecture. > The rationale for MOVNTI instruction is supposed to be that it avoids cache pollution. Aside from the bench that shows MOVNTI to be faster for the move itself, shouldn't it have an additional benefit in not trashing the CPU caches? As string instructions improve, why wouldn't the same improvements be applied to MOVNTI?