On Tue, Jan 12, 2016 at 10:27:07AM +0100, Arnd Bergmann wrote: > On Tuesday 12 January 2016 19:29:57 Dave Chinner wrote: > > > > This is what I meant about premature optimisation - you've got a > > wonderfully complex solution to a problem that we don't need to > > solve to support timestamps >y2038. It's also why it goes down the > > wrong path at this point - most of the changes are not necessary if > > all we need to do is a simple timespec -> timespec64 type change and > > the addition timestamp range limiting in the existing truncation > > function... > > I originally suggested doing the split representation because I > was worried about the downsides of using timespec64 on 32-bit systems > after looking at actual memory consumption on my test box. > > At this moment, I have a total of 145712700 inodes in memory on a machine Is that all? :P > with 64GB ram, saving 12 bytes on each amounts to a total of 145MB. I just posted a patchset that knocks 104 bytes off the XFS inode (~12% reduction in size). We need the changes in that patchset to sanely support >y2038k support in XFS, and it means we now won't need to grow the XFS inode to add that support, either. > I think > it was more than that when I first looked, so it's between 0.2% and 0.3% > of savings in total memory, which is certainly worth discussing about, > given the renewed interest in conserving RAM in general. If we want to > save this memory, then doing it at the same time as the timespec64 conversion > is the right time so we don't need to touch every file twice. You just uttered the key words: "If we want to save this memory" So let's stop conflating two different lines of development because we only actually *need* y2038k support. The fact we haven't made timestamp space optimisations means that nobody has thought it necessary or worthwhile. y2038k support doesn't change the landscape under which we might consider the optimisation, so we need to determine if the benefit outweighs the cost in terms of code complexity and maintainability. So separate the two changes - make the y2038k change simple and obviously correct first by changing everything to timespec64. Then it won't get delayed by bikeshedding about an optimisation of that is of questionable benefit. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
