From: Matthew Wilcox <willy@infradead.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Michal Hocko <mhocko@kernel.org>,
Cannon Matthews <cannonmatthews@google.com>,
Andi Kleen <ak@linux.intel.com>,
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: Thu, 26 Mar 2020 12:46:11 -0700 [thread overview]
Message-ID: <20200326194611.GN22483@bombadil.infradead.org> (raw)
In-Reply-To: <20200316121955.tqmhu57evzafc2cl@box>
On Mon, Mar 16, 2020 at 03:19:55PM +0300, Kirill A. Shutemov wrote:
> On Mon, Mar 16, 2020 at 11:18:56AM +0100, Michal Hocko wrote:
> > While this might be true, isn't that easily solveable by the existing
> > ALTERNATIVE and cpu features framework. Can we have a feature bit to
> > tell that movnti is worthwile for large data copy routines. Probably
> > something for x86 maintainers.
>
> It still need somody to test which approach is better for the CPU.
> See X86_FEATURE_REP_GOOD.
How about inverting the sense of the bit? Set it on Broadwell-and-
earlier CPUs, where it definitely improves performance by a huge amount,
and new microarches can set it if it still outperforms rep mov?
next prev parent reply other threads:[~2020-03-26 19:46 UTC|newest]
Thread overview: 27+ 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 1:03 ` Cannon Matthews
2020-03-07 15:36 ` kbuild test robot
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: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
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 [this message]
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=20200326194611.GN22483@bombadil.infradead.org \
--to=willy@infradead.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.