Re: [GIT PULL] tracing: Fixes for 6.6-rc2

[Linus Torvalds]

On Mon, 25 Sept 2023 at 07:53, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> These dentries and inodes are allocated for the top level directory and
> wasting memory for most users. When an instance is created it makes
> matters even worse.

So honestly, dentries are *tiny*. They are probably not any bigger
than the backing data structures you use to keep track of the names in
teh first place.

The memory cost is likely almost from the inodes, which are indeed
pretty big and fat.

> If there's a better way to achieve the same thing, I'll happily do it.

Do you actually *need* individual inodes for each of the entries in tracefd?

Because I think the *big* memory savings would be to use one single
inode for every file (make directories have individual inodes,
anything else will confuse user-space 'pwd' etc mightily)

Then you'd

 (a) have the actual tracefs-specific data in dentry->d_fsdata

 (b) use "-inode->i_op->getattr()" to make the stat() info look
different for different files (if you even care, but you might)

and I think that would be most of it.

You might hit some gotcha somewhere - things like "dcache_readdir()
will take the inode number just from the inode, and there's no
callback for it", so if you care about showing unique inode numbers to
user space, we might need to help you out some way.

But that "reuse a single inode" is actually a very traditional
pattern, even if I suspect that pattern doesn't remain anywhere. /proc
used to do things like that, iirc.

                        Linus