[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071201132047.2bf3c40c@the-village.bc.nu>
Date: Sat, 1 Dec 2007 13:20:47 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Adrian Bunk <bunk@...nel.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Avoid overflows in kernel/time.c
On Sat, 1 Dec 2007 01:33:33 +0100
Adrian Bunk <bunk@...nel.org> wrote:
> On Thu, Nov 29, 2007 at 04:19:51PM -0800, H. Peter Anvin wrote:
> > When the conversion factor between jiffies and milli- or microseconds
> > is not a single multiply or divide, as for the case of HZ == 300, we
> > currently do a multiply followed by a divide. The intervening
> > result, however, is subject to overflows, especially since the
> > fraction is not simplified (for HZ == 300, we multiply by 300 and
> > divide by 1000).
> >...
> > kernel/Makefile | 8 +++
> > kernel/time.c | 29 +++++++++---
> > kernel/timeconst.bc | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 152 insertions(+), 8 deletions(-)
> > create mode 100644 kernel/timeconst.bc
> >...
>
> I have read the hep text, but are the advantages of HZ == 300 really
> visible or was this more theoretical?
Its visibile for people doing PAL media processing and TV sync work.
Longer term we have high precision timers and tickless so for now we can
jut do the HZ == 300 math in steps to avoid the overflow. Slower but in
time it won't matter.
Alan
--
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