> As about the broken calling conventions of the IA32 ABI, I think it
> doesn't worth to break the binary compatibility at this late stage.
We are not at any late stage. The new 64-bit PC processors might
be accepted about as well as Microchannel and EISA were accepted.
Crummy old 32-bit
As about the broken calling conventions of the IA32 ABI, I think it
doesn't worth to break the binary compatibility at this late stage.
We are not at any late stage. The new 64-bit PC processors might
be accepted about as well as Microchannel and EISA were accepted.
Crummy old 32-bit
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Fri, Nov 17, 2000 at 05:06:49PM +0100, Christoph Rohland wrote:
> > Could I get this for i686? :-)
>
> If we break binary compatibility yes.
OK, I'll stick to rdtsc on ix86
Christoph
-
To unsubscribe from this list: send the line
Andrea Arcangeli [EMAIL PROTECTED] writes:
On Fri, Nov 17, 2000 at 05:06:49PM +0100, Christoph Rohland wrote:
Could I get this for i686? :-)
If we break binary compatibility yes.
OK, I'll stick to rdtsc on ix86
Christoph
-
To unsubscribe from this list: send the line
On Fri, Nov 17, 2000 at 05:06:49PM +0100, Christoph Rohland wrote:
> Could I get this for i686? :-)
If we break binary compatibility yes. I mean: new glibc binaries wouldn't
run anymore on older kernels. Also new static binaries wouldn't run
anymore on older kernels. At least if we don't
Hi Andrea,
On Fri, 17 Nov 2000, Andrea Arcangeli wrote:
> So as worse you'll have to wait x86-64 to get that lightweight
> vgettimeofday.
Could I get this for i686? :-)
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, Nov 17, 2000 at 01:51:11PM +0100, Christoph Rohland wrote:
> gettimeofday is _way_ to slow for a lot of every day uses. So
> applications will use rdtsc until we have some really fast
> (non-syscall) way to have high resolution time diffs.
During the x86-64 design I made sure that in
> > I thought Linux kernel does synchronize them on boot? So, you are
> > saying I cannot rely on this being 100% correct?
>
> Yes, it does so far. And if we cannot assume this to be correct in the
> microsecond scale on smp machines with homogenous non-powersaving cpus
> we will loose on some
Hi Tigran,
On Fri, 17 Nov 2000, Tigran Aivazian wrote:
> On Fri, 17 Nov 2000, Andi Kleen wrote:
>> [of course rdtsc only works properly on UP or with bind_cpu()]
>
> I thought Linux kernel does synchronize them on boot? So, you are
> saying I cannot rely on this being 100% correct?
Yes, it
In article <[EMAIL PROTECTED]> you wrote:
> Andi Kleen wrote:
>> No it would not. Often you want cycle accurate couting for profiling
>> purposes.
> Isn't that why /dev/cpu/%d/msr exists?
This is root only though..
(Yes, you can crash AMD boxes by reading MSR's)
Greetings,
Arjan van de
On Fri, Nov 17, 2000 at 08:40:27AM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> > No it would not. Often you want cycle accurate couting for profiling
> > purposes.
>
> Isn't that why /dev/cpu/%d/msr exists?
Requires either root privileges or is a big security hole.
[of course rdtsc only
Andi Kleen wrote:
> No it would not. Often you want cycle accurate couting for profiling
> purposes.
Isn't that why /dev/cpu/%d/msr exists?
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To
Hmm, my CPUID vs /proc/cpuinfo comment seemed somewhat controversial.
Tigran Aivazian wrote:
> Arguably, it is always better to parse /proc/cpuinfo instead of executing
> CPUID directly (think PCI -- drivers should _NOT_ get their irq/io/etc
> values from config space directly but only what
On Fri, Nov 17, 2000 at 02:21:03PM +0100, Christoph Rohland wrote:
> Hi Jeff,
>
> On Fri, 17 Nov 2000, Jeff Garzik wrote:
> > IIRC, this came up a long time ago WRT Apache, which made a lot of
> > gettimeofday() calls. Someone (Linus?) proposed the solution of a
> > 'magic page' which holds
It used to be..
flags : fpu vme de pse tsc msr pae
but now called features
It's a simple enough change. Contact me privately if you can't any
avifile people to help.
Jordan wrote:
>
> I have been running a plug in for xmms for some time that uses the
> aviplay program and
Hi Jeff,
On Fri, 17 Nov 2000, Jeff Garzik wrote:
> IIRC, this came up a long time ago WRT Apache, which made a lot of
> gettimeofday() calls. Someone (Linus?) proposed the solution of a
> 'magic page' which holds information like gettimeofday() stuff, but
> could be handled much more rapidly
Christoph Rohland wrote:
>
> Hi Alan,
>
> On Fri, 17 Nov 2000, Alan Cox wrote:
> > Even checking the cpuinfo for the TSC should be done with care, and
> > its far far better to use gettimeofday unless doing very tiny
> > timings (eg for optimising code paths)
>
> gettimeofday is _way_ to slow
Hi Alan,
On Fri, 17 Nov 2000, Alan Cox wrote:
> Even checking the cpuinfo for the TSC should be done with care, and
> its far far better to use gettimeofday unless doing very tiny
> timings (eg for optimising code paths)
gettimeofday is _way_ to slow for a lot of every day uses. So
applications
On Fri, Nov 17, 2000 at 01:14:30PM +0100, Jan Niehusmann wrote:
> On Fri, Nov 17, 2000 at 01:04:18PM +0100, Andi Kleen wrote:
> > The program would be broken if it executed CPUID itself, because it has no way to
>guarantee
> > that the CPUID is executed on all CPUs the scheduler may later move
On Fri, Nov 17, 2000 at 01:04:18PM +0100, Andi Kleen wrote:
> The program would be broken if it executed CPUID itself, because it has no way to
>guarantee
> that the CPUID is executed on all CPUs the scheduler may later move the task too.
I wonder what's the right way for an app to ask the
> > You have a user-space program which parses /proc/cpuinfo instead of
> > executing CPUID itself, so it breaks.
>
> Arguably, it is always better to parse /proc/cpuinfo instead of executing
Actually this is definitively the case.
It is not safe to use cpuid to check the availability of
On Fri, Nov 17, 2000 at 12:39:59PM +0100, Mikael Pettersson wrote:
> Jordan writes:
> > I have been running a plug in for xmms for some time that uses the
> > aviplay program and avifile library...then when upgrading to test5/6 I
> > start getting this error message when running xmms:
> >
>
On Fri, 17 Nov 2000, Mikael Pettersson wrote:
> You have a user-space program which parses /proc/cpuinfo instead of
> executing CPUID itself, so it breaks.
Hi Mikael,
Arguably, it is always better to parse /proc/cpuinfo instead of executing
CPUID directly (think PCI -- drivers should _NOT_ get
Jordan writes:
> I have been running a plug in for xmms for some time that uses the
> aviplay program and avifile library...then when upgrading to test5/6 I
> start getting this error message when running xmms:
>
> ERROR: no time-stamp counter found! Quitting.
> ...
> contents of
I have been running a plug in for xmms for some time that uses the
aviplay program and avifile library...then when upgrading to test5/6 I
start getting this error message when running xmms:
ERROR: no time-stamp counter found! Quitting.
I finally trace it down to my avi plugin and then from
I have been running a plug in for xmms for some time that uses the
aviplay program and avifile library...then when upgrading to test5/6 I
start getting this error message when running xmms:
ERROR: no time-stamp counter found! Quitting.
I finally trace it down to my avi plugin and then from
Jordan writes:
I have been running a plug in for xmms for some time that uses the
aviplay program and avifile library...then when upgrading to test5/6 I
start getting this error message when running xmms:
ERROR: no time-stamp counter found! Quitting.
...
contents of /proc/cpuinfo:
On Fri, 17 Nov 2000, Mikael Pettersson wrote:
You have a user-space program which parses /proc/cpuinfo instead of
executing CPUID itself, so it breaks.
Hi Mikael,
Arguably, it is always better to parse /proc/cpuinfo instead of executing
CPUID directly (think PCI -- drivers should _NOT_ get
On Fri, Nov 17, 2000 at 12:39:59PM +0100, Mikael Pettersson wrote:
Jordan writes:
I have been running a plug in for xmms for some time that uses the
aviplay program and avifile library...then when upgrading to test5/6 I
start getting this error message when running xmms:
ERROR:
You have a user-space program which parses /proc/cpuinfo instead of
executing CPUID itself, so it breaks.
Arguably, it is always better to parse /proc/cpuinfo instead of executing
Actually this is definitively the case.
It is not safe to use cpuid to check the availability of RDTSC in
On Fri, Nov 17, 2000 at 01:04:18PM +0100, Andi Kleen wrote:
The program would be broken if it executed CPUID itself, because it has no way to
guarantee
that the CPUID is executed on all CPUs the scheduler may later move the task too.
I wonder what's the right way for an app to ask the kernel
On Fri, Nov 17, 2000 at 01:14:30PM +0100, Jan Niehusmann wrote:
On Fri, Nov 17, 2000 at 01:04:18PM +0100, Andi Kleen wrote:
The program would be broken if it executed CPUID itself, because it has no way to
guarantee
that the CPUID is executed on all CPUs the scheduler may later move the
Hi Alan,
On Fri, 17 Nov 2000, Alan Cox wrote:
Even checking the cpuinfo for the TSC should be done with care, and
its far far better to use gettimeofday unless doing very tiny
timings (eg for optimising code paths)
gettimeofday is _way_ to slow for a lot of every day uses. So
applications
Christoph Rohland wrote:
Hi Alan,
On Fri, 17 Nov 2000, Alan Cox wrote:
Even checking the cpuinfo for the TSC should be done with care, and
its far far better to use gettimeofday unless doing very tiny
timings (eg for optimising code paths)
gettimeofday is _way_ to slow for a lot of
Hi Jeff,
On Fri, 17 Nov 2000, Jeff Garzik wrote:
IIRC, this came up a long time ago WRT Apache, which made a lot of
gettimeofday() calls. Someone (Linus?) proposed the solution of a
'magic page' which holds information like gettimeofday() stuff, but
could be handled much more rapidly than a
It used to be..
flags : fpu vme de pse tsc msr pae
but now called features
It's a simple enough change. Contact me privately if you can't any
avifile people to help.
Jordan wrote:
I have been running a plug in for xmms for some time that uses the
aviplay program and
On Fri, Nov 17, 2000 at 02:21:03PM +0100, Christoph Rohland wrote:
Hi Jeff,
On Fri, 17 Nov 2000, Jeff Garzik wrote:
IIRC, this came up a long time ago WRT Apache, which made a lot of
gettimeofday() calls. Someone (Linus?) proposed the solution of a
'magic page' which holds information
Hmm, my CPUID vs /proc/cpuinfo comment seemed somewhat controversial.
Tigran Aivazian wrote:
Arguably, it is always better to parse /proc/cpuinfo instead of executing
CPUID directly (think PCI -- drivers should _NOT_ get their irq/io/etc
values from config space directly but only what the
Andi Kleen wrote:
No it would not. Often you want cycle accurate couting for profiling
purposes.
Isn't that why /dev/cpu/%d/msr exists?
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To
On Fri, Nov 17, 2000 at 08:40:27AM -0500, Jeff Garzik wrote:
Andi Kleen wrote:
No it would not. Often you want cycle accurate couting for profiling
purposes.
Isn't that why /dev/cpu/%d/msr exists?
Requires either root privileges or is a big security hole.
[of course rdtsc only works
In article [EMAIL PROTECTED] you wrote:
Andi Kleen wrote:
No it would not. Often you want cycle accurate couting for profiling
purposes.
Isn't that why /dev/cpu/%d/msr exists?
This is root only though..
(Yes, you can crash AMD boxes by reading MSR's)
Greetings,
Arjan van de Ven
-
Hi Tigran,
On Fri, 17 Nov 2000, Tigran Aivazian wrote:
On Fri, 17 Nov 2000, Andi Kleen wrote:
[of course rdtsc only works properly on UP or with bind_cpu()]
I thought Linux kernel does synchronize them on boot? So, you are
saying I cannot rely on this being 100% correct?
Yes, it does so
I thought Linux kernel does synchronize them on boot? So, you are
saying I cannot rely on this being 100% correct?
Yes, it does so far. And if we cannot assume this to be correct in the
microsecond scale on smp machines with homogenous non-powersaving cpus
we will loose on some
On Fri, Nov 17, 2000 at 01:51:11PM +0100, Christoph Rohland wrote:
gettimeofday is _way_ to slow for a lot of every day uses. So
applications will use rdtsc until we have some really fast
(non-syscall) way to have high resolution time diffs.
During the x86-64 design I made sure that in x86-64
Hi Andrea,
On Fri, 17 Nov 2000, Andrea Arcangeli wrote:
So as worse you'll have to wait x86-64 to get that lightweight
vgettimeofday.
Could I get this for i686? :-)
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
45 matches
Mail list logo
