[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
> >> Not within today's Xen or Linux (which both assume a global kernel > >> address space, in particular non-root page table entries > >> mapping kernel > >> space to be the same in all address spaces - you'd need > >> separate entries > >> at all levels for this). > > > > OK, I forgot: No software-accessible TLB. > > > > Can you think of any trick (that doesn't require the cost of a > > trap/hypercall) to allow an app to determine what pcpu > > it is running on? > > I can't think of any that don't require kernel modifications. > Which takes us > back to considering vsyscall, perhaps. > > -- Keir If a solution that doesn't require kernel mods is not possible, then I suspect apps will continue to use rdtsc as-is and suffer the emulation overhead. Requiring all customers to update the OS underlying these apps is a non-starter. Also, it has yet to be proven that pvclock can work in a vsyscall. Doesn't the same per-cpu in userspace problem exist? Pvclock without vsyscall has been measured and is too slow, so until a vsyscall version of pvclock is implemented and measured (let alone upstream or available in distros), it's hard to call it an alternative to consider, even for the future. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |