lcd4linux-devel

[Lcd4linux-devel] rdtscl() on i386

[Bernhard W. <ber...@gm...>]

Hello,

following kernel commit has removed rdtcl() from being exported in
userspace. It’s now inside __KERNEL__ ifdef.

    commit 4bc5aa91fb1e544ad37805520030a0d9fc6e11d3
    Author: H. Peter Anvin <hp...@zy...>
    Date:   Wed May 2 19:27:12 2007 +0200

    [PATCH] x86: Clean up x86 control register and MSR macros (corrected)

    This patch is based on Rusty's recent cleanup of the EFLAGS-related
    macros; it extends the same kind of cleanup to control registers and
    MSRs.

    It also unifies these between i386 and x86-64; at least with regards
    to MSRs, the two had definitely gotten out of sync.

    Signed-off-by: H. Peter Anvin <hp...@zy...>
    Signed-off-by: Andi Kleen <ak...@su...>


Therefore, checking if <asm/msr.h> exists is not sufficient any more. rdtscl()
is also problematic on multi-core systems. I guess it's time to get rid of
rdtscl() ...



Thanks,
   Bernhard

Re: [Lcd4linux-devel] rdtscl() on i386

[Michael R. <re...@eu...>]

Hi Bernhard,

> following kernel commit has removed rdtcl() from being exported in
> userspace. It=92s now inside __KERNEL__ ifdef.
>=20
> Therefore, checking if <asm/msr.h> exists is not sufficient any more. r=
dtscl()
> is also problematic on multi-core systems. I guess it's time to get rid=
 of
> rdtscl() ...

I agree, especially for another reason: rdtsc() is problematic with=20
power-saving by CPU frequency scaling...

But what to use else? There's a fallback to a gettimeofday() busy loop;=20
but this loop is quite ressource-intensive...

Is there by any chance a senseful possibility to get small delays=20
(without reschedule) in userspace?

udelay() and friends would work, but only if changing the scheduler to=20
SCHED_RT (which is what I definitely do *not* like)


Any hints would be greatly appreciated!


TIA, Michael

--=20
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781