Re: binary format loader cache?

Ingo Molnar (mingo@pc5829.hil.siemens.at)
Mon, 7 Apr 1997 22:38:14 +0200 (MET DST)


On Mon, 7 Apr 1997 tytso@mit.edu wrote:

> is anyone working on the above thing? It looks like an overkill to look up
> the very same ~3 binary loaders for every do_exec() in a typical Linux
> system, and wasting some ~300 usecs (or more) per lookup.
>
> We should very clearly change the binfmt interfaces so that open_inode()
> is called by do_execve(), instead of opening the file each time for
> binary format. [...]

the point is that we dont move /bin/ld.so or /bin/bash around too often,
and we do not modify them. Still we do a lookup for every binary format
loading currently. I know it's complex, as an inode's name depends on many
things like the path directory list leading up to the inode, and we have
to maintain exact matching between the binary loader name (which is
contained in the to-be-run executable), and the inode that is (or should
be) behind it. Plus there might be user-dependent things, like one user
not being able to run a binary loader, while the other one can run it ...

basically we need to know about 'modification events' which modify the
inode belonging to a name. ... is there some nice field in struct inode
that tells us about any name modification? If yes then we could cache the
inodes leading up to the binary loader, and we could check against this
'version' field, and we would do a lookup if any of the fields changed.

Still the question is, do we really need all the inode namespace
complexity for binary handler lookup?

-- mingo