All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zengtao (B)" <prime.zeng@hisilicon.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Arnd Bergmann <arnd@arndb.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: RE: [PATCH] cputime: Fix timeval-->cputime conversion
Date: Tue, 2 Feb 2016 02:57:40 +0000	[thread overview]
Message-ID: <678F3D1BB717D949B966B68EAEB446ED0A6B5D2A@SZXEMA509-MBX.china.huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1602010942150.25254@nanos>

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@linutronix.de]
> Sent: Monday, February 01, 2016 4:43 PM
> To: Zengtao (B)
> Cc: Arnd Bergmann; LKML; Frederic Weisbecker
> Subject: RE: [PATCH] cputime: Fix timeval-->cputime conversion
> 
> On Mon, 1 Feb 2016, Zengtao (B) wrote:
> 
> > Hi Arnd:
> > 	I have got a new idea about the problem:
> > In include/linux/time64.h
> > #define NSEC_PER_SEC	1000000000L
> > I think we should change it to
> > #define NSEC_PER_SEC	1000000000LL
> >
> > My reason is :
> > 1.  when it is used in a multiplication, it will easily get overflow.
> > 2.  when it don't get overflow, the change has no side affect.
> 
> That's not a good idea. NSEC_PER_SEC is used in lots of places with 32bit
> storage. I really don't want to mop up all the fallout.

Yes, agree, a lot of places it has been used as 32bit value. Beyond that, I think 
it is more reasonable to use 64bit. 

> 
> Thanks,
> 
> 	tglx
> 

      reply	other threads:[~2016-02-02  2:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28  7:02 [PATCH] cputime: Fix timeval-->cputime conversion zengtao
2016-01-28  8:22 ` Thomas Gleixner
2016-01-28 11:52   ` Arnd Bergmann
2016-01-29  3:12     ` Zengtao (B)
2016-01-29  8:46       ` Arnd Bergmann
2016-01-30  2:31         ` Zengtao (B)
2016-02-01  3:51         ` Zengtao (B)
2016-02-01  8:43           ` Thomas Gleixner
2016-02-02  2:57             ` Zengtao (B) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=678F3D1BB717D949B966B68EAEB446ED0A6B5D2A@SZXEMA509-MBX.china.huawei.com \
    --to=prime.zeng@hisilicon.com \
    --cc=arnd@arndb.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.