From: Steven Whitehouse <steve@xxxxxxxxxxxxxx>
Date: Tue, 11 Dec 2001 11:14:39 +0000 (GMT)
> These things aren't like inodes. Inodes are cached and lookup
> read-multiple objects, whereas sockets are throw-away and recycled
> objects. Inode allocation performance therefore isn't that critical,
> but socket allocation performance is.
>
We do have to allocate an inode as well though (at least in the normal
case) and with the new (if I've understood the conclusions of the
discussions on inode allocation) scheme this would give us a single
allocation which would be sizeof(struct inode) + sizeof(struct socket)
in a slab cache private to sockfs.
Indeed, you are right. But I don't know about the inode+socket idea.
I wonder if we could allocate a combined object along the lines of the
following:
a) struct inode
b) struct socket
c) struct sock (minus per protocol areas)
d) struct my_protocol (whatever the socket actually is)
e) anything else required
all in one go.
The reference counting would be a pain in the neck, I think.
If we can somehow "genericize" the "inode + extra stuff" into
some abstraction, sure maybe.
I don't know, it could work.
|