All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Harry Yoo <harry.yoo@oracle.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	"Tobin C. Harding" <tobin@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>, Rik van Riel <riel@surriel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
	David Hildenbrand <david@redhat.com>,
	Oscar Salvador <osalvador@suse.de>,
	Michal Hocko <mhocko@kernel.org>,
	Byungchul Park <byungchul@sk.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [DISCUSSION] Revisiting Slab Movable Objects
Date: Wed, 23 Apr 2025 08:40:39 +0100	[thread overview]
Message-ID: <20250423074039.GE2023217@ZenIV> (raw)
In-Reply-To: <aAiUtCKJOdWjYxDZ@harry>

On Wed, Apr 23, 2025 at 04:20:20PM +0900, Harry Yoo wrote:

> If we can't migrate or reclaim dentries with a nonzero refcount,
> can we at least prevent slab pages from containing a mix of dentries
> with zero and nonzero refcounts?
> 
> An idea: "Migrate a dentry (and inode?) _before_ it becomes unrelocatable"
> This is somewhat similar to "Migrate a page out of the movable area before
> pinning it" in MM.
> 
> For example, suppose we have two slab caches for dentry:
> dentry_cache_unref and dentry_cache_ref.
> 
> When a dentry with a zero refcount is about to have its refcount
> incremented, the VFS allocates a new object from dentry_cache_ref, copies
> the dentry into it, frees the original dentry back to
> dentry_cache_unref, and returns the newly allocated object.
> 
> Similarly when a dentry with a nonzero refcount drops to zero,
> it is migrated to dentry_cache_unref. This should be handled on the VFS
> side rather than by the slab allocator.
> 
> This approach could, at least, help reduce fragmentation.

No.  This is utterly insane - you'd need to insert RCU delay on each
of those transitions and that is not to mention the frequency with
which those will happen on a lot of loads (any kind of builds included).
Not a chance.

  reply	other threads:[~2025-04-23  7:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-21 13:47 [DISCUSSION] Revisiting Slab Movable Objects Harry Yoo
2025-04-21 16:33 ` Pedro Falcato
2025-04-22 23:17   ` Harry Yoo
2025-04-23  5:53   ` Christoph Lameter (Ampere)
2025-04-21 21:54 ` Dave Chinner
2025-04-23  1:47   ` Al Viro
2025-04-23  7:20     ` Harry Yoo
2025-04-23  7:40       ` Al Viro [this message]
2025-04-25 11:09   ` Harry Yoo
2025-04-28 15:31     ` Jann Horn
2025-04-30 13:11       ` Harry Yoo
2025-04-30 22:23         ` Jann Horn
2025-05-05 23:29         ` Dave Chinner
2025-04-21 21:59 ` Tobin C. Harding

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=20250423074039.GE2023217@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=Liam.Howlett@oracle.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=byungchul@sk.com \
    --cc=cl@linux.com \
    --cc=david@fromorbit.com \
    --cc=david@redhat.com \
    --cc=harry.yoo@oracle.com \
    --cc=jannh@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pfalcato@suse.de \
    --cc=riel@surriel.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=tobin@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=willy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.