On Wed, Jul 26, 2006 at 01:26:07AM +0200, Segher Boessenkool wrote:
> >>But userland cannot know if there is a more efficient option to
> >>use than this /dev/rtc way, without using VDSO/vsyscall.
> >>
> >Sure, but detecting if /dev/rtc via mmap is faster than
> >gettimeofday is an
> >orthogonal issue to having the choice in the first place.
>
> No it's not. Userland can not detect things it doesn't know
> about, and then when there is a great choice, it won't see it,
> and use the 6000kW solution (or any other really bad thing)
> instead.
>
You're right, it won't be easy for an application to detect if gettimeofday uses
a vdso that is more lightweight than a regular syscall, but it can measure how
much cpu a periodic call to gettimeofday uses vs. how much cpu a periodic rtc
interrupt uses. It can use that information to make an informed decision about
which interface to use. Alternatively, a package can be built with sane
defaults in mind (always use RTC vs. always use gettimeofday).
> Using the old old legacy stuff when there's nothing better around
> is a fine idea; please just implement an x86 VDSO that does just
> that. x86 is what you care about IIUC. Don't saddle up non-x86
> systems that just happen to have a legacy RTC around, and perhaps
> x86 systems that don't sanely expose their better interfaces, with
> this quite suboptimal solution for years to come.
>
Yes, I intend to (I've got a steep learning curve, since I've not worked much
with glibc, and I've never implemented a vdso call before), but I think thats a
great idea. My point is, why not have both interfaces available? That way,
implementations which can't do any better via a vdso call can still get a
speedup through the legacy interface.
Neil
>
> Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
