Re: [RFC] [PATCH] Clean up fs.h union for ext2

Arnaldo Carvalho de Melo (acme@conectiva.com.br)
Mon, 7 Jan 2002 00:18:13 -0200


Em Mon, Jan 07, 2002 at 03:12:06AM +0100, Daniel Phillips escreveu:
> On January 7, 2002 02:27 am, Arnaldo Carvalho de Melo wrote:
> > When I did similar work for the network protocols, cleaning up
> > include/net/fs.h DaveM asked for benchmarks to see if the new approach,
> > i.e., using per network family slabcaches would lead to a performance drop,
> > I did it and we realized that it lead to performance _gains_, that in turn
> > made DaveM ask for a per network protocol slabcache, which made furter
> > memory savings and lead to further performance gains.
>
> Oh, so that's why you were too busy to do the fs.h patch ;-)

*grin* And I still have to break the ipv6_sk_cachep into tcp6_sk_cachep,
udp6_sk_cachep and raw6_sk_cachep and test if moving the IPv4 identity
members in struct sock (sport, dport, saddr, rcv_saddr, daddr, etc) to
struct inet_opt is ok performance wise, doing that would remove the last
remnants of protocol specific stuff from include/net/sock.h 8)

<SNIP>

> Even if we leave the generic_ip in the common inode, we will for sure remove
> the union at some point, meaning that even filesystems that use the
> generic_ip now will have to do a big edit to clean up the fallout. Which
> isn't such a bad thing I suppose.

yes, in the sock.h cleanup the protinfo big union turned into just a void
pointer.

> If we wanted to be lazy, we could just leave the union there, with one
> element, the generic_ip. How ugly would that be?

Well, it can be left for later, first step would be to abstract the access
to the private areas in all the filesystems, but hey, don't worry as as
from the quick look I had some of the filesystems already use abstractions
for such access, like MSDOS_I, ext3 already does, NTFS NG also, etc 8)

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/