Hi,
On Monday 17 December 2007, H. Peter Anvin wrote:
> kernel/timeconst.pl | 340
I agree with Jan that it would be better to put this into scripts.
In the long term we could also detect some of the simple special cases, so we
can finally inline some of these functions again, this w
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
On Mon, 17 Dec 2007 13:53:23 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> 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, h
On Dec 17 2007 15:33, H. Peter Anvin wrote:
>> Could this live in scripts/ too? (And use CodingStyle?)
>
> Why should it live in scripts/ rather than where it is used? scripts/ is used
> either for global scripts or scripts which are used manually. Other scripts
> are
> not centralized there.
>
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
> diff --git a/kernel/Makefile b/kernel/Makefile
> index dfa9695..749825a 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -80,3 +80,11 @@ quiet_cmd_ikconfiggz = IKCFG $@
> targets += config_data.h
> $(obj)/config_data.h: $(obj)/config_data.gz FORCE
> $(call if_changed,ikconfig
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
Jan Engelhardt wrote:
On Dec 17 2007 13:53, H. Peter Anvin wrote:
index 000..fd46b3d
--- /dev/null
+++ b/kernel/timeconst.pl
Could this live in scripts/ too? (And use CodingStyle?)
Why should it live in scripts/ rather than where it is used? scripts/
is used either for global scripts
On Dec 17 2007 13:53, H. Peter Anvin wrote:
>index 000..fd46b3d
>--- /dev/null
>+++ b/kernel/timeconst.pl
Could this live in scripts/ too? (And use CodingStyle?)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
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
On Mon, 10 Dec 2007 10:59:20 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >
> > My ia64 allmodconfig build has taken
> >
> > akpm 15700 89.6 0.0 8256 700 pts/4RN+ 03:09 10:41 bc -q
> > kernel/timeconst.bc
> >
> > 11 minutes so far. fc6/x86_64.
> >
Andrew Morton wrote:
My ia64 allmodconfig build has taken
akpm 15700 89.6 0.0 8256 700 pts/4RN+ 03:09 10:41 bc -q
kernel/timeconst.bc
11 minutes so far. fc6/x86_64.
I just tried this on my system, using your cross-compiler chain. I got
a different error:
/opt/crosstool/
Andrew Morton wrote:
My ia64 allmodconfig build has taken
akpm 15700 89.6 0.0 8256 700 pts/4RN+ 03:09 10:41 bc -q
kernel/timeconst.bc
11 minutes so far. fc6/x86_64.
Just got back from a week off-net. Will look into promptly.
That's obviously ridiculous.
-hpa
--
T
Jan Engelhardt wrote:
On Nov 29 2007 19:54, H. Peter Anvin wrote:
Arjan van de Ven wrote:
Anyway, I don't think compiling bc is hard on anything which has a C
compiler.
alternative is to just also ship the precomputed values ;-)
Oh, come on... it's not like bc is some obscure thing. It's a
Adrian Bunk 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 intervenin
On Thu, 29 Nov 2007 16:19:51 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> 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, h
On Nov 29 2007 19:54, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
>> >
>> > Anyway, I don't think compiling bc is hard on anything which has a C
>> > compiler.
>>
>> alternative is to just also ship the precomputed values ;-)
>>
>
> Oh, come on... it's not like bc is some obscure thing. It'
On Thu 2007-11-29 19:54:44, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
> >>
> >>Anyway, I don't think compiling bc is hard on anything
> >>which has a C compiler.
> >
> >alternative is to just also ship the precomputed values
> >;-)
> >
>
> Oh, come on... it's not like bc is some obscure th
Alan Cox wrote:
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.
Just use the patch... I don't think a de
On Sat, 1 Dec 2007 13:20:47 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sat, 1 Dec 2007 01:33:33 +0100
> Adrian Bunk <[EMAIL PROTECTED]> 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
> >
On Sat, 1 Dec 2007 01:33:33 +0100
Adrian Bunk <[EMAIL PROTECTED]> 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
> > currentl
Adrian Bunk wrote:
I have read the hep text, but are the advantages of HZ == 300 really
visible or was this more theoretical?
In the latter case, we might remove the HZ == 300 choice instead.
Well, we have, for various architectures:
HZ == 48, 100, 128, 250, 256, 300, 1000, 1024
You'd ha
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 subje
Arjan van de Ven wrote:
Anyway, I don't think compiling bc is hard on anything which has a C
compiler.
alternative is to just also ship the precomputed values ;-)
Oh, come on... it's not like bc is some obscure thing. It's a POSIX
utility.
-hpa
-
To unsubscribe from this list:
On Thu, 29 Nov 2007 19:04:36 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Chris Snook wrote:
> > H. Peter Anvin wrote:
> >> NOTE: This patch uses a bc(1) script to compute the appropriate
> >> constants.
> >
> > Perhaps dc would be more appropriate? That's included in busybox.
> >
>
> P
Chris Snook wrote:
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
Perhaps it would, but I think there is more variability between dc
implementations -- consider if the busyb
Andrew Morton wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Does this add the first dependency upon the availability of bc?
I believe it does. I used bc because doing it C would have required
arbitrary-precision code or have added a dependency on libgmp.
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
On Thu, 29 Nov 2007 16:19:51 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> 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, h
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
30 matches
Mail list logo