linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems
Date: Fri, 26 Jan 2024 06:16:38 -0800	[thread overview]
Message-ID: <2024012634-rotten-conjoined-0a98@gregkh> (raw)
In-Reply-To: <20240125214007.67d45fcf@rorschach.local.home>

On Thu, Jan 25, 2024 at 09:40:07PM -0500, Steven Rostedt wrote:
> On Thu, 25 Jan 2024 17:59:40 -0800
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > > I tried to use kernfs when doing a lot of this and I had issues. I
> > > don't remember what those were, but I can revisit it.  
> > 
> > You might, as kernfs makes it so that the filesystem structures are
> > created on demand, when accessed, and then removed when memory pressure
> > happens.  That's what sysfs and configfs and cgroups use quite
> > successfully.
> 
> kernfs doesn't look trivial and I can't find any documentation on how
> to use it.

You have the code :)

> Should there be work to move debugfs over to kernfs?

Why?  Are you seeing real actual memory use with debugfs that is causing
problems?  That is why we made kernfs, because people were seeing this
in sysfs.

Don't change stuff unless you need to, right?

> I could look at it too, but as tracefs, and more specifically eventfs,
> has 10s of thousands of files, I'm very concerned about meta data size.

Do you have real numbers?  If not, then don't worry about it :)

> Currently eventfs keeps a data structure for every directory, but for
> the files, it only keeps an array of names and callbacks. When a
> directory is registered, it lists the files it needs. eventfs is
> specific that the number of files a directory has is always constant,
> and files will not be removed or added once a directory is created.
> 
> This way, the information on how a file is created is done via a
> callback that was registered when the directory was created.

That's fine, and shouldn't matter.

> For this use case, I don't think kernfs could be used. But I would
> still like to talk about what I'm trying to accomplish, and perhaps see
> if there's work that can be done to consolidate what is out there.

Again, look at kernfs if you care about the memory usage of your virtual
filesystem, that's what it is there for, you shouldn't have to reinvent
the wheel.

And the best part is, when people find issues with scaling or other
stuff with kernfs, your filesystem will then benifit (lots of tweaks
have gone into kernfs for this over the past few kernel releases.)

thanks,

greg k-h


  reply	other threads:[~2024-01-26 14:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25 15:48 [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems Steven Rostedt
2024-01-26  1:24 ` Greg Kroah-Hartman
2024-01-26  1:50   ` Steven Rostedt
2024-01-26  1:59     ` Greg Kroah-Hartman
2024-01-26  2:40       ` Steven Rostedt
2024-01-26 14:16         ` Greg Kroah-Hartman [this message]
2024-01-26 15:15           ` Steven Rostedt
2024-01-26 15:41             ` Greg Kroah-Hartman
2024-01-26 16:44               ` Steven Rostedt
2024-01-27 10:15                 ` Amir Goldstein
2024-01-27 14:54                   ` Steven Rostedt
2024-01-27 14:59                   ` James Bottomley
2024-01-27 18:06                     ` Matthew Wilcox
2024-01-27 19:44                       ` Linus Torvalds
2024-01-27 20:23                         ` James Bottomley
2024-01-29 15:08                         ` Christian Brauner
2024-01-29 15:57                           ` Steven Rostedt
2024-01-27 20:07                       ` James Bottomley

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=2024012634-rotten-conjoined-0a98@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).