Message-ID: <1412862026.32718.19.camel@jarvis>
Date:	Thu, 09 Oct 2014 06:40:26 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Ebru Akagunduz <ebru.akagunduz@...il.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	opw-kernel@...glegroups.com
Subject: Re: [PATCH] scsi: ips.c: use 64-bit time types

On Wed, 2014-10-08 at 22:58 +0200, Arnd Bergmann wrote:
> On Wednesday 08 October 2014 13:44:55 James Bottomley wrote:
> > > diff --git a/drivers/scsi/ips.h b/drivers/scsi/ips.h
> > > index 45b9566..ff2a0b3 100644
> > > --- a/drivers/scsi/ips.h
> > > +++ b/drivers/scsi/ips.h
> > > @@ -1054,7 +1054,7 @@ typedef struct ips_ha {
> > >     uint8_t            active;
> > >     int                ioctl_reset;        /* IOCTL Requested Reset Flag */
> > >     uint16_t           reset_count;        /* number of resets           */
> > > -   time_t             last_ffdc;          /* last time we sent ffdc info*/
> > > +   time64_t             last_ffdc;          /* last time we sent ffdc info*/
> > >     uint8_t            slot_num;           /* PCI Slot Number            */
> > >     int                ioctl_len;          /* size of ioctl buffer       */
> > >     dma_addr_t         ioctl_busaddr;      /* dma address of ioctl buffer*/
> > 
> > This is completely pointless, isn't it?  All the ips driver cares about
> > is that we send a FFDC time update every eight hours or so, so we can
> > happily truncate the number of seconds to 32 bits for that calculation
> > just keep the variable at 32 bits and do a time_after thing for the
> > comparison.
> 
> Good point. The same has come up in a few other places, so I wonder if we
> should introduce a proper way to do it that doesn't involve time_t.

We have, it's jiffies ... that's why I'm slightly non-plussed that this
driver is using gettimeofday for something like this ... it was clearly
a review failure when we put it in.

or are you thinking we need a time_t_time_before doing for time_t what
we do for jiffies?

> While the current code works, we will have to audit 2000 other locations
> in which time_t/timespec/timeval are used in the kernel, so we are going
> to need some form of annotation to make sure we don't get everyone to
> look at the driver again just to come to the same conclusion after working
> on a patch first.
> 
> > However, what the code *should* be doing is using jiffies and
> > time_before/after since the interval is so tiny rather than a
> > do_gettimeofday() call in the fast path.
> 
> Yes, this would probably be best for this particular driver, it also
> means we end up with a monotonic clock source rather than a wall-clock.

Right, and it's a 32 bit read instead of a system call every time the
thing dispatches a command ... to be honest the overhead of 64 bit
arithmetic is peanuts to making a syscall in the fast path.

James

> Ebru, when I explained the various data types we have for timekeeping,
> I failed to mention jiffies. That is one that is very fast to access
> and has a resolution between 1 and 10 milliseconds but will overflow
> within a few months, so it can only be used in places where overflow
> is known to be handled safely, as time_before() does.
> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists