Message-ID: <CABeXuvpzRy=qccBqq70iT_W9EGSfcpAjfyqkayUTT01F8Ghh5g@mail.gmail.com>
Date:	Mon, 20 Jun 2016 11:58:31 -0700
From:	Deepa Dinamani <deepa.kernel@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Theodore Ts'o" <tytso@....edu>, Al Viro <viro@...iv.linux.org.uk>,
	y2038 Mailman List <y2038@...ts.linaro.org>,
	"adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Anna Schumaker <anna.schumaker@...app.com>,
	Brian Uchino <buchino@...co.com>,
	ceph-devel <ceph-devel@...r.kernel.org>,
	Chris Mason <clm@...com>, Changman Lee <cm224.lee@...sung.com>,
	Artem Bityutskiy <dedekind1@...il.com>,
	David Sterba <dsterba@...e.com>, Alex Elder <elder@...nel.org>,
	Eric Paris <eparis@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Hiral Patel <hiralpat@...co.com>,
	Ilya Dryomov <idryomov@...il.com>, Jan Kara <jack@...e.com>,
	Jaegeuk Kim <jaegeuk@...nel.org>, Josef Bacik <jbacik@...com>,
	"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
	jfs-discussion@...ts.sourceforge.net,
	Joel Becker <jlbec@...lplan.org>,
	John Stultz <john.stultz@...aro.org>, linux-audit@...hat.com,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"Linux F2FS DEV, Mailing List" 
	<linux-f2fs-devel@...ts.sourceforge.net>,
	linux-mtd <linux-mtd@...ts.infradead.org>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Linux SCSI List <linux-scsi@...r.kernel.org>,
	lustre-devel@...ts.lustre.org,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Mark Fasheh <mfasheh@...e.com>, ocfs2-devel@....oracle.com,
	Paul Moore <paul@...l-moore.com>, Sage Weil <sage@...hat.com>,
	Steve French <sfrench@...ba.org>,
	Dave Kleikamp <shaggy@...nel.org>,
	Suma Ramars <sramars@...co.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	"Yan, Zheng" <zyan@...hat.com>
Subject: Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

> This version now looks ok to me.
>
> I do have a comment (or maybe just a RFD) for future work.
>
> It does strike me that once we actually change over the inode times to
> use timespec64, the calling conventions are going to be fairly
> horrendous on most 32-bit architectures.
>
> Gcc handles 8-byte structure returns (on most architectures) by
> returning them as two 32-bit registers (%edx:%eax on x86). But once it
> is timespec64, that will no longer be the case, and the calling
> convention will end up using a pointer to the local stack instead.
>
> So for 32-bit code generation, we *may* want to introduce a new model of doing
>
>     set_inode_time(inode, ATTR_ATIME | ATTR_MTIME);
>
> which basically just does
>
>     inode->i_atime = inode->i_mtime = current_time(inode);
>
> but with a much easier calling convention on 32-bit architectures.

Arnd and I had discussed something like this before.
But, for entirely different reasons:

Having the set_inode_time() like you suggest will also help switching
of vfs inode times to timespec64.
We were suggesting all the accesses to inode time be abstracted
through something like inode_set_time().
Arnd also had suggested a split representation of fields in the struct
inode as well which led to space savings
as well. And, having the split representation also meant no more
direct assignments:

https://lkml.org/lkml/2016/1/7/20

This in general will be similar to setattr_copy(), but only sets times
rather than other attributes as well.

If this is what is preferred, then the patches to change vfs to use
timespec64 could make use of this and will
need to be refactored. So maybe it would be good to discuss before I
post those patches.

-Deepa

Powered by blists - more mailing lists