From: Arvind Sankar <nivedita@alum.mit.edu>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
Cannon Matthews <cannonmatthews@google.com>,
Matthew Wilcox <willy@infradead.org>,
Andi Kleen <ak@linux.intel.com>, Michal Hocko <mhocko@kernel.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
Greg Thelen <gthelen@google.com>, Salman Qazi <sqazi@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] mm: clear 1G pages with streaming stores on x86
Date: Wed, 11 Mar 2020 14:32:41 -0400 [thread overview]
Message-ID: <20200311183240.GA3880414@rani.riverdale.lan> (raw)
In-Reply-To: <20200311081607.3ahlk4msosj4qjsj@box>
On Wed, Mar 11, 2020 at 11:16:07AM +0300, Kirill A. Shutemov wrote:
> On Tue, Mar 10, 2020 at 11:35:54PM -0400, Arvind Sankar wrote:
> >
> > 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?
>
> String instructions inherently more flexible. Implementation can choose
> caching strategy depending on the operation size (cx) and other factors.
> Like if operation is large enough and cache is full of dirty cache lines
> that expensive to free up, it can choose to bypass cache. MOVNTI is more
> strict on semantics and more opaque to CPU.
But with today's processors, wouldn't writing 1G via the string
operations empty out almost the whole cache? Or are there already
optimizations to prevent one thread from hogging the L3?
If we do want to just use the string operations, it seems like the
clear_page routines should just call memset instead of duplicating it.
>
> And more importantly string instructions, unlike MOVNTI, is something that
> generated often by compiler and used in standard libraries a lot. It is
> and will be focus of optimization of CPU architects.
>
> --
> Kirill A. Shutemov
next prev parent reply other threads:[~2020-03-11 18:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 1:03 [PATCH] mm: clear 1G pages with streaming stores on x86 Cannon Matthews
2020-03-07 15:36 ` kbuild test robot
2020-03-07 22:06 ` Andrew Morton
2020-03-09 0:08 ` Kirill A. Shutemov
2020-03-09 9:06 ` Michal Hocko
2020-03-09 9:35 ` Kirill A. Shutemov
2020-03-09 11:36 ` Kirill A. Shutemov
2020-03-09 12:26 ` Michal Hocko
2020-03-09 18:01 ` Mike Kravetz
2020-03-09 15:38 ` Andi Kleen
2020-03-09 18:37 ` Matthew Wilcox
2020-03-11 0:21 ` Cannon Matthews
2020-03-11 0:54 ` Kirill A. Shutemov
2020-03-11 3:35 ` Arvind Sankar
2020-03-11 8:16 ` Kirill A. Shutemov
2020-03-11 18:32 ` Arvind Sankar [this message]
2020-03-11 20:32 ` Arvind Sankar
2020-03-12 0:52 ` Kirill A. Shutemov
2020-03-31 0:40 ` Elliott, Robert (Servers)
2020-03-16 10:18 ` Michal Hocko
2020-03-16 12:19 ` Kirill A. Shutemov
2020-03-26 19:46 ` Matthew Wilcox
2020-03-11 15:07 ` David Laight
2020-03-09 15:33 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200311183240.GA3880414@rani.riverdale.lan \
--to=nivedita@alum.mit.edu \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=cannonmatthews@google.com \
--cc=gthelen@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=rientjes@google.com \
--cc=sqazi@google.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).