[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240122145919.3eb8f9b9@gandalf.local.home>
Date: Mon, 22 Jan 2024 14:59:19 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Kees Cook
<keescook@...omium.org>, Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>, Mark
Rutland <mark.rutland@....com>, Andrew Morton <akpm@...ux-foundation.org>,
Christian Brauner <brauner@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Ajay Kaher <ajay.kaher@...adcom.com>
Subject: Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files
and directories all be the same
On Mon, 22 Jan 2024 13:35:43 -0500
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> > When an inode is no longer referenced, it is freed. When it is referenced
> > again, I want it to be recreated with the same inode number it had
> > previously. How would having a bitmask help with that? I need a way to map
> > an ei structure with a unique number without adding another 4 bytes to the
> > structure itself.
>
> As discussed in a separate exchange with Linus, why do you care so much about
> not adding a 4 bytes field to the structure ?
I'm trying to keep the memory overhead of tracing down as much as possible.
4 bytes for 2000 events (and growing) just adds to the memory footprint of
tracing.
And an eventfs_inode is the link between control of an event per instance.
Thus, it may only be 8k for those 2000 events, but that's another 8k for
each instance you use. You make 10 instances, that is now 80k.
This is used in embedded systems as well, so every byte counts.
But as Linus pointed out, the issue is moot, as the structure ends with a
single 32bit int. And on 64 bit machines, there's likely a 4 byte hole that
we can use there.
-- Steve
Powered by blists - more mailing lists