From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54874 invoked by alias); 27 Nov 2017 18:49:48 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 54864 invoked by uid 89); 27 Nov 2017 18:49:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:2873, inclination, H*Ad:U*rth X-HELO: out03.mta.xmission.com From: ebiederm@xmission.com (Eric W. Biederman) To: Paul Eggert Cc: Arnd Bergmann , John Stultz , Thomas Gleixner , y2038@lists.linaro.org, libc-alpha@sourceware.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Albert ARIBAUD , Richard Henderson , Ivan Kokshaysky , Matt Turner , Al Viro , Ingo Molnar , Frederic Weisbecker , Deepa Dinamani , Greg Kroah-Hartman , Oleg Nesterov , Andrew Morton , Kirill Tkhai , linux-alpha@vger.kernel.org References: <20171127170121.634826-1-arnd@arndb.de> <20171127170121.634826-3-arnd@arndb.de> <34369a6e-e0ce-fe7b-65e3-9c4a33e4789a@cs.ucla.edu> Date: Mon, 27 Nov 2017 18:49:00 -0000 In-Reply-To: <34369a6e-e0ce-fe7b-65e3-9c4a33e4789a@cs.ucla.edu> (Paul Eggert's message of "Mon, 27 Nov 2017 09:52:06 -0800") Message-ID: <87o9nnlfpq.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1eJOTH-0003mr-9A;;;mid=<87o9nnlfpq.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18IAN7Frj8WFaBpST6Lmj+ZbrxG73qlgSA= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.2 T_XMDrugObfuBody_14 obfuscated drug references X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Paul Eggert X-Spam-Relay-Country: X-Spam-Timing: total 5297 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.1 (0.0%), b_tie_ro: 1.54 (0.0%), parse: 0.68 (0.0%), extract_message_metadata: 9 (0.2%), get_uri_detail_list: 1.43 (0.0%), tests_pri_-1000: 3.2 (0.1%), tests_pri_-950: 0.91 (0.0%), tests_pri_-900: 0.77 (0.0%), tests_pri_-400: 24 (0.5%), check_bayes: 23 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 9 (0.2%), b_comp_prob: 2.4 (0.0%), b_tok_touch_all: 3.3 (0.1%), b_finish: 0.51 (0.0%), tests_pri_0: 267 (5.0%), check_dkim_signature: 0.42 (0.0%), check_dkim_adsp: 4.4 (0.1%), tests_pri_500: 4987 (94.2%), poll_dns_idle: 4982 (94.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 3/3] y2038: rusage: use __kernel_old_timeval for process times X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-SW-Source: 2017-11/txt/msg00950.txt.bz2 Paul Eggert writes: > On 11/27/2017 09:00 AM, Arnd Bergmann wrote: >> b) Extend the approach taken by the x32 ABI, and use the 64-bit >> native structure layout for rusage on all architectures with new >> system calls that is otherwise compatible. A possible problem here >> is that we end up with incompatible definitions of rusage between >> /usr/include/linux/resource.h and /usr/include/bits/resource.h >> >> c) Change the definition of struct rusage to be independent of >> time_t. This is the easiest change, as it does not involve new system >> call entry points, but it has the risk of introducing compile-time >> incompatibilities with user space sources that rely on the type >> of ru_utime and ru_stime. >> >> I'm picking approch c) for its simplicity, but I'd like to hear from >> others whether they would prefer a different approach. > > (c) would break programs like GNU Emacs, which copy ru_utime and ru_stime > members into struct timeval variables. > > All in all, (b) sounds like it would be better for programs using glibc, as it's > more compatible with what POSIX apps expect. Though I'm not sure what problems > are meant by "possible ... incompatible definitions"; perhaps you could > elaborate. getrusage is posix and I believe the use of struct timeval is posix as well. So getrusage(3) the libc definition and that defintion must struct timeval or the implementation will be non-conforming and it won't be just emacs we need to worry about. The practical question is what do we provide to userspace so that it can implement a conforming getrusage? A 32bit time_t based struct timeval is good for durations up to 136 years or so. Which strongly suggests the range is large enough, except for some crazy massively multi-threaded application. And anything off the charts cpu hungry at this point I expect will be 64bit. It is possible to get a 128 way system with one thread on each core and consume 100% of the core for a bit over a year to max out getrusage. So I do think in the long run we care about increasing the size of time_t here. Last I checked applications doing things like that were 64bit in the year 2000. Given that userspace is going to be seeing the larger struct rusage in any event my inclination for long term maintainability would be to introduce the new syscall and have the current one called oldgetrusage on 32bit architectures. Then we won't have to worry about what weird things glibc will do when translating the data, and we can handle applications with crazy (but possible) runtimes. Which inclines me to (b) as well. As for (a) does anyone have a need for process acounting at nsec granularity? Unless we can get that for free that just seems like overpromising and a waist to have so much fine granularity. Eric