From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: SeongJae Park <sj38.park@gmail.com>
Cc: SeongJae Park <sjpark@amazon.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Date: Thu, 12 Aug 2021 13:28:13 -0400 [thread overview]
Message-ID: <167751.1628789293@turing-police> (raw)
In-Reply-To: <20210812094240.4492-1-sjpark@amazon.de>
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
On Thu, 12 Aug 2021 09:42:40 -0000, SeongJae Park said:
> - This feature adds PG_idle and PG_young flags in 'struct page'. PTE
> - Accessed bit writers can set the state of the bit in the flags to let
> - other PTE Accessed bit readers don't disturbed.
> + This feature adds 'PG_idle' and 'PG_young' flags in 'struct page'.
> + PTE Accessed bit writers can save the state of the bit in the flags
> + to let other PTE Accessed bit readers don't get disturbed.
Well, better English would be "to let other ... not be disturbed'.
But I was rather hoping for an explanation of what "don't get disturbed" actually means.
If you are "save the state of the bit", are you saving the *previous* value (in
which case, other readers of the bit may or may not encounter changed behavior),
or are you saving a shadow copy that may have different values than the original
flags, and only used by a few routines?
Or are you creating two new status flags that are only used by several
optimized/fastpath routines and ignored by the other readers of the various
flag bits?
So a better description would be something like
This feature adds two new status bits PG_idle and PG_young to 'struct page'.
This allows passing additional information to certain users of PTE Accessed so
they can use an optimized codepath bypassing expensive checks for certain
common cases.
or "so they can provide <describe different behavior>"
or whatever this option is doing.
[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]
next prev parent reply other threads:[~2021-08-12 17:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-12 9:21 Valdis Klētnieks
2021-08-12 9:42 ` SeongJae Park
2021-08-12 17:28 ` Valdis Klētnieks [this message]
2021-08-12 20:19 ` Re: Andrew Morton
2021-08-13 8:14 ` Re: SeongJae Park
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=167751.1628789293@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj38.park@gmail.com \
--cc=sjpark@amazon.de \
/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).