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 with 64GB ram, saving 12 bytes on each amounts to a total of 145MB. 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. One point that I had not considered though is on the 32-bit systems we are talking about, not only is RAM much smaller, but also there would be a smaller fraction of RAM available to store inodes, so there is not as much to gain. Arnd -- 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
