On Oct 28, 2002 05:42 +0100, Andi Kleen wrote:
> Andreas Dilger <adilger@clusterfs.com> writes:
> > 1) It would be good if it were possible to select this with a config
> > option (I don't care which way the default goes), so that people who
> > don't need/care about the increased resolution don't need the extra
> > space in their inodes and minor extra overhead. To make this a lot
> > easier to code, having something akin to the inode_update_time()
> > which does all of the i_[acm]time updates as appropriate.
>
> You're joking right? That's twelve bytes of more state per struct inode
> and I bet even with the most insidious micro benchmark you won't be
> able to detect a difference in speed from the basic manipulation.
Except that people have a lot of inodes in their slab caches... It's not
so much the processing overhead as the extra memory. struct inode is
bloated enough without adding more into it that isn't necessarily useful
for some people (people who don't have lots of RAM, or don't use any
filesystems which support the higher resolution, or are slow enough that
compiles don't have problems, or don't compile at all)...
Cheers, Andreas
-- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/- 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/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:35 EST