From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934657AbcALJ1V (ORCPT ); Tue, 12 Jan 2016 04:27:21 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:60528 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933472AbcALJ1M (ORCPT ); Tue, 12 Jan 2016 04:27:12 -0500 From: Arnd Bergmann To: y2038@lists.linaro.org Cc: Dave Chinner , Deepa Dinamani , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time Date: Tue, 12 Jan 2016 10:27:07 +0100 Message-ID: <4788428.RCG4WOvRdT@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160112082957.GG6033@dastard> References: <1452144972-15802-1-git-send-email-deepa.kernel@gmail.com> <20160112054235.GA63984@myubuntu.deepaubuntu.g7.internal.cloudapp.net> <20160112082957.GG6033@dastard> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:7MnIidDH9VNmseATR+CrF+Zt7dNWe3XsYtY3tlmQXJJ1OJ1guGI Xmq29lanISMGA04xI9ibUkxWL08ssPZyoSwzI+SeuXdqS4ZiT9i4c0l6oUEub9//KGmJjla dT/zeCIWO84cpUj0VsMMbGnlc/wJ353RaOqMVEQtucnBaebwniihnceSZsOIC+zoQCd8qEx 2JZWbdKmCGccEb6RdxkUg== X-UI-Out-Filterresults: notjunk:1;V01:K0:YbXLUI39oII=:NlwL/BLzZSZYTyA3qbMuft 9h1nqGphkOuhYF4TM8jdrrnBmmtFzCglm8uRtnVEm7txpG7eZ+fe4It8erk78YK/r6G7FVKTl cCzwpJTgUTDAx0jZfv9Nl7o+zVtceTXVnSMkI4C47BhAt2K8NdjelJrOIhS4Dlg36APNskQ7y 81pDafnpEvTr0AGqd2XdaH/Zn5QNhoEcLW7J+nIyhSIrccRkPz3xQ6PV/RrfQ7hyM8P5dCqCG ZHMbYhaikgama0vCFv4/kd/VL5TDbLeBW+CQ6700bwiC8u1DMTh6S2mc0b7+YW/KiOeyQlp7o BB5ylS432SYRgjB8jxW9pEln0PkqCnAuLNflppSSVFBQkd9hsCsKAhvVtQZmfErXvKo66F+uy PRwJV6Go3Udd49SQcvC31ZiaHFkdh1VLMGqEAQJoZJVwDvTFzW95EoqXs6e7AS6MEKwGLrlrJ AHQ6JJYpfB62uAhOysvwWprkbFXi35zFLky/U+1lzATgYzSQzhffjB0HKzp3o4T2PnJVsSxvF YGnaIM/tKM1yB3HYef7nL/hEww0LTIiGPdhSy8jYaSNkLrXV9+ASf5hP8qyvtAVPU1WOUv37O yPlyi+qyTtGziO23/UDMIi/XkVrgQLVvGbzDXKe7qhnOXuyKz6KwPy37NjO1wlsJbafqhvDvE +uwlQkswug8N3uBZyaq/7bZDLY617A9Akn2dvaCvB2Nk7suYMf/telFWV0gggCmpY6nNU8jNT h+pZN0DYsu4qDAi+ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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