Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753193AbcKRWyG (ORCPT ); Fri, 18 Nov 2016 17:54:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33004 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753066AbcKRWyF (ORCPT ); Fri, 18 Nov 2016 17:54:05 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20161118220744.GC31101@dastard> References: <20161118220744.GC31101@dastard> <147938969703.13574.10295364502230379833.stgit@warthog.procyon.org.uk> <147938970382.13574.11581172952175034619.stgit@warthog.procyon.org.uk> <20161117234047.GE28177@dastard> To: Dave Chinner Cc: dhowells@redhat.com, Andreas Dilger , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11316.1479509642.1@warthog.procyon.org.uk> Date: Fri, 18 Nov 2016 22:54:02 +0000 Message-ID: <11317.1479509642@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 18 Nov 2016 22:54:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2431 Lines: 72 Dave Chinner wrote: > And when we start thinking in those timeframes, an > increase in timestamp resoultion of at least another 10e-3 is > likely.... Is it, though? To be useful, surely you have to be able to jam quite a few instructions into a 1ns block, including memory accesses. Rather than providing: struct timestamp { __s64 seconds; __s64 femtoseconds; }; which would require 64-bit divisions to get nanosecond timestamps that we do actually use, I would lean towards: struct timestamp { __s64 seconds; __s32 nanoseconds; __s32 femtoseconds; }; where the fields are, in effect, additive. Which means I could represent this as: __s64 stx_atime_s; /* Last access time */ __s64 stx_btime_s; /* File creation time */ __s64 stx_ctime_s; /* Last attribute change time */ __s64 stx_mtime_s; /* Last data modification time */ __s32 stx_atime_ns; /* Last access time (ns part) */ __s32 stx_btime_ns; /* File creation time (ns part) */ __s32 stx_ctime_ns; /* Last attribute change time (ns part) */ __s32 stx_mtime_ns; /* Last data modification time (ns part) */ and then add: __s32 stx_atime_fs; /* Last access time (fs part) */ __s32 stx_btime_fs; /* File creation time (fs part) */ __s32 stx_ctime_fs; /* Last attribute change time (fs part) */ __s32 stx_mtime_fs; /* Last data modification time (fs part) */ later. If we *really* do want to allow for atto- or femto- second resolution timestamps (and you've still not entirely convinced me that it's going to be necessary - the speed of signal propagation still has an ungetroundable limit), then we could stick the space in now - but I think it's likely to remain dead space. Maybe we should switch to Windows-style timestamp resolution: struct timestamp { __s64 hundred_ns; /* Time in 100ns increments */ __s32 femtoseconds; /* Additional fs component */ }; > > Using the existing FS_*_FL flags as initial values is not worse than > > starting with any other arbitrary values for the flags. > > Except it starts with a sparse set of flags for no good reason. Actually, a very good reason. You can map those flags, on ext4 at least, with a load, an AND and an OR. Three instructions[*]. If the bits don't correspond, it gets more expensive (4-5 instructions per bit + 1). [*] Leastways, it *should* be three instructions, but gcc fails to optimise it correctly. I have a bz logged for this. David