> 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 processo
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 "uns
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 introduc
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 x86-
> > 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 be
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
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?
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe
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 wor
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 uns
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 th
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 info
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 av
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 tha
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 f
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 th
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 kerne
> > 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
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 t
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/cpu
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 ther
24 matches
Mail list logo
