LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
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 --]

  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 \
    --subject='Re: ' \
    /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

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).