From: Jann Horn <jannh@google.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: linux-man <linux-man@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Mark Mossberg <mark.mossberg@gmail.com>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] proc.5: Document inaccurate RSS due to SPLIT_RSS_COUNTING
Date: Tue, 27 Oct 2020 11:35:35 +0100 [thread overview]
Message-ID: <CAG48ez2gigjfi3_nmbyhDnb2bsi9K0Yc24y7HdSNDvtumWGbiw@mail.gmail.com> (raw)
In-Reply-To: <0a090c14-6b70-4284-bb2d-4fbfd1146aaf@gmail.com>
On Tue, Oct 27, 2020 at 8:05 AM Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> On 10/12/20 4:52 PM, Jann Horn wrote:
> > On Mon, Oct 12, 2020 at 1:49 PM Jann Horn <jannh@google.com> wrote:
> >> Since 34e55232e59f7b19050267a05ff1226e5cd122a5 (introduced back in
> >> v2.6.34), Linux uses per-thread RSS counters to reduce cache contention on
> >> the per-mm counters. With a 4K page size, that means that you can end up
> >> with the counters off by up to 252KiB per thread.
> >
> > Actually, as Mark Mossberg pointed out to me off-thread, the counters
> > can actually be off by many times more...
>
> So, does your patch to proc.5 need tweaking, or can I just apply as is?
The "(up to 63 pages per thread)" would have to go, the rest should be correct.
But as Michal said, if someone volunteers to get rid of this
optimization, maybe we don't need the documentation after all? But
that would probably require actually doing some careful
heavily-multithreaded benchmarking on a big machine with a few dozen
cores, or something like that, so that we know whether this
optimization actually is unimportant enough that we can just get rid
of it...
next prev parent reply other threads:[~2020-10-27 10:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-12 11:49 Jann Horn
2020-10-12 14:52 ` Jann Horn
2020-10-27 7:05 ` Michael Kerrisk (man-pages)
2020-10-27 10:35 ` Jann Horn [this message]
2020-10-27 12:18 ` Michal Hocko
2020-10-27 13:49 ` Michal Hocko
2020-10-27 13:49 ` Michael Kerrisk (man-pages)
2020-10-12 15:07 ` Michal Hocko
2020-10-12 15:20 ` Jann Horn
2020-10-12 15:33 ` Michal Hocko
2020-10-27 18:56 ` Vlastimil Babka
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=CAG48ez2gigjfi3_nmbyhDnb2bsi9K0Yc24y7HdSNDvtumWGbiw@mail.gmail.com \
--to=jannh@google.com \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.mossberg@gmail.com \
--cc=mhocko@suse.com \
--cc=mtk.manpages@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox