From: "Huang\, Ying" <ying.huang@intel.com>
To: Chintan Pandya <chintan.pandya@oneplus.com>
Cc: Michal Hocko <mhocko@suse.com>,
Prathu Baronia <prathu.baronia@oneplus.com>,
"akpm\@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm\@kvack.org" <linux-mm@kvack.org>,
"gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"gthelen\@google.com" <gthelen@google.com>,
"jack\@suse.cz" <jack@suse.cz>, Ken Lin <ken.lin@oneplus.com>,
Gasine Xu <Gasine.Xu@Oneplus.com>
Subject: Re: [RFC] mm/memory.c: Optimizing THP zeroing routine for !HIGHMEM cases
Date: Fri, 10 Apr 2020 17:05:36 +0800 [thread overview]
Message-ID: <87lfn390db.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <SG2PR04MB2921D2AAA8726318EF53D83691DE0@SG2PR04MB2921.apcprd04.prod.outlook.com> (Chintan Pandya's message of "Fri, 10 Apr 2020 07:00:34 +0000")
Chintan Pandya <chintan.pandya@oneplus.com> writes:
>> I do realize that the initialization improvement patch doesn't really mention
>> any real life usecase either. It is based on a microbenchmark but the objective
>> sounds reasonable. If it regresses some other workloads then we either have to
>> make it conditional or find out what is causing the regression and how much
>
> Generally, many architectures are optimized for serial loads, be it initialization or
> access, as it is simplest form of prediction. Any random access pattern would kill
> that pre-fetching. And for now, I suspect that to be the case here. Probably, we
> can run more tests to confirm this part.
Please prove your theory with test. Better to test x86 too.
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2020-04-10 9:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 8:18 [RFC] mm/memory.c: Optimizing THP zeroing routine for !HIGHMEM cases Prathu Baronia
2020-04-03 8:52 ` Michal Hocko
2020-04-09 15:29 ` Prathu Baronia
2020-04-09 15:45 ` Michal Hocko
[not found] ` <SG2PR04MB2921D2AAA8726318EF53D83691DE0@SG2PR04MB2921.apcprd04.prod.outlook.com>
2020-04-10 9:05 ` Huang, Ying [this message]
2020-04-11 15:40 ` Chintan Pandya
2020-04-11 20:47 ` Alexander Duyck
2020-04-13 15:33 ` Prathu Baronia
2020-04-13 16:24 ` Alexander Duyck
2020-04-14 1:10 ` Huang, Ying
2020-04-10 18:54 ` Alexander Duyck
2020-04-11 8:45 ` Chintan Pandya
2020-04-14 15:55 ` Daniel Jordan
2020-04-14 17:33 ` Chintan Pandya
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=87lfn390db.fsf@yhuang-dev.intel.com \
--to=ying.huang@intel.com \
--cc=Gasine.Xu@Oneplus.com \
--cc=akpm@linux-foundation.org \
--cc=chintan.pandya@oneplus.com \
--cc=gregkh@linuxfoundation.org \
--cc=gthelen@google.com \
--cc=jack@suse.cz \
--cc=ken.lin@oneplus.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=prathu.baronia@oneplus.com \
/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.