From: Michal Hocko <mhocko@kernel.org>
To: Daniel Colascione <dancol@google.com>
Cc: Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] Synchronize task mm counters on context switch
Date: Tue, 27 Feb 2018 11:02:34 +0100 [thread overview]
Message-ID: <20180227100234.GF15357@dhcp22.suse.cz> (raw)
In-Reply-To: <CAKOZueukEggFEL-UkvQeOirPQcamcyDZdcEV5V2z9AZ7QB_p2Q@mail.gmail.com>
[CC Kamezawa]
On Fri 23-02-18 10:47:16, Daniel Colascione wrote:
> On Fri, Feb 23, 2018 at 9:50 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Fri 23-02-18 08:34:19, Daniel Colascione wrote:
[...]
> >> Maybe I'm wrong, but I feel like taking page faults will touch per-mm
> >> data structures anyway, so one additional atomic update on the mm
> >> shouldn't hurt all that much.
> >
> > I wouldn't be oppposed to remove it completely if it is not measureable.
>
> Just deleting SPLIT_RSS_COUNTING is certainly my preferred option. I
> didn't see any benchmarks accompanying the inclusion of the mechanism
> in the first place.
You are right that 34e55232e59f ("mm: avoid false sharing of
mm_counter") was rather poor on the testing and convincing numbers. It
is not really clear where
[before]
4.5 cache-miss/faults
[after]
4.0 cache-miss/faults
come from.
> How would you suggest verifying that we can safely
> delete it?
Heavy parallel page fault test but you would have to be careful to not
measure the page allocator overhead.
> I *think* it would have the greatest benefit on very large
> systems with lots of tasks sharing and mm, each taking page faults
> often, but I don't have any such large machines.
The more I think about it the more I am convinced that we should simply
disable SPLIT_RSS_COUNTING by default or even remove the code
altogether.
Kamezawa, did you or anybody else have any specific workload which
benefited from this change or it was merely "this sounds like a good
optimization" thingy?
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-02-27 10:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 22:03 [PATCH] Synchronize task mm counters on context switch Daniel Colascione
2018-02-21 19:05 ` Daniel Colascione
2018-02-22 0:16 ` Minchan Kim
2018-02-22 0:23 ` Daniel Colascione
2018-02-22 2:06 ` Minchan Kim
2018-02-22 2:46 ` [PATCH] Synchronize task mm counters on demand Daniel Colascione
2018-02-23 2:01 ` Minchan Kim
2018-02-23 2:09 ` Daniel Colascione
2018-02-23 2:24 ` Daniel Colascione
2018-02-23 2:28 ` Minchan Kim
2018-02-23 2:43 ` Daniel Colascione
2018-02-23 3:12 ` Minchan Kim
2018-02-23 9:50 ` f66871fb4c: WARNING:inconsistent_lock_state kernel test robot
2018-02-22 2:49 ` [PATCH] Synchronize task mm counters on context switch Daniel Colascione
2018-02-23 8:11 ` Michal Hocko
2018-02-23 16:34 ` Daniel Colascione
2018-02-23 17:50 ` Michal Hocko
2018-02-23 18:47 ` Daniel Colascione
2018-02-27 10:02 ` Michal Hocko [this message]
2018-02-22 9:40 ` Peter Zijlstra
2018-02-22 13:06 ` Minchan Kim
2018-02-22 16:23 ` Daniel Colascione
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=20180227100234.GF15357@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dancol@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.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).