Linux-ide Archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org,
	bpf@vger.kernel.org
Subject: [LSF/MM/BPF TOPIC] Reclaiming & documenting page flags
Date: Mon, 29 Jan 2024 04:32:03 +0000	[thread overview]
Message-ID: <Zbcn-P4QKgBhyxdO@casper.infradead.org> (raw)

Our documentation of the current page flags is ... not great.  I think
I can improve it for the page cache side of things; I understand the
meanings of locked, writeback, uptodate, dirty, head, waiters, slab,
mlocked, mappedtodisk, error, hwpoison, readahead, anon_exclusive,
has_hwpoisoned, hugetlb and large_remappable.

Where I'm a lot more shaky is the meaning of the more "real MM" flags,
like active, referenced, lru, workingset, reserved, reclaim, swapbacked,
unevictable, young, idle, swapcache, isolated, and reported.

Perhaps we could have an MM session where we try to explain slowly and
carefully to each other what all these flags actually mean, talk about
what combinations of them make sense, how we might eliminate some of
them to make more space in the flags word, and what all this looks like
in a memdesc world.

And maybe we can get some documentation written about it!  Not trying
to nerd snipe Jon into attending this session, but if he did ...

[thanks to Amir for reminding me that I meant to propose this topic]

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org,
	bpf@vger.kernel.org
Subject: [LSF/MM/BPF TOPIC] Reclaiming & documenting page flags
Date: Fri, 2 Feb 2024 16:28:58 +0000	[thread overview]
Message-ID: <Zbcn-P4QKgBhyxdO@casper.infradead.org> (raw)
Message-ID: <20240202162858.Ls92Xc_5ujibp6MKKLacpn7ZJoRy5v-IqVIwYhM8BmI@z> (raw)

LFrom willy@infradead.org Fri Feb  2 16:28:25 2024
Date: Fri, 2 Feb 2024 16:28:25 +0000
From: Matthew Wilcox <willy@infradead.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [resend, PATCH v1 1/1] logic_pio: Use RESOURCE_SIZE_MAX
 definition
References: <20231016132611.1201402-1-andriy.shevchenko@linux.intel.com>
 <Zb0LzpBkE71wWyqO@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zb0LzpBkE71wWyqO@smile.fi.intel.com>
X-Mutt-References: <Zb0LzpBkE71wWyqO@smile.fi.intel.com>
X-Mutt-Fcc: ~/sent
Status: RO
Content-Length: 237
Lines: 7

On Fri, Feb 02, 2024 at 05:35:42PM +0200, Andy Shevchenko wrote:
> On Mon, Oct 16, 2023 at 04:26:11PM +0300, Andy Shevchenko wrote:
> > Use a predefined limit instead of hardcoding it.
> 
> Can we apply this one?

Why are you asking me?

             reply	other threads:[~2024-01-29  4:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29  4:32 Matthew Wilcox [this message]
2024-02-02 16:28 ` [LSF/MM/BPF TOPIC] Reclaiming & documenting page flags Matthew Wilcox
2024-02-04 10:39 ` Mike Rapoport
2024-02-04 21:34   ` Matthew Wilcox
2024-02-07 15:51     ` Mike Rapoport
2024-02-19 20:13       ` Matthew Wilcox
2024-02-19 22:45         ` NeilBrown
2024-02-19 23:29           ` Matthew Wilcox
2024-02-20  0:21             ` NeilBrown
2024-02-20  7:16         ` Hannes Reinecke
2024-02-17 11:57 ` Muhammad Usama Anjum
2024-05-17 21:32 ` Navid

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=Zbcn-P4QKgBhyxdO@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=bpf@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.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 read-only IMAP folder(s) and NNTP newsgroup(s).