* Re: Use of barriers in pvclock ABI [not found] ` <489FE56E.1080707@redhat.com> @ 2008-08-11 14:15 ` Avi Kivity [not found] ` <5d6222a80808110718i6a600858v7bdb5e08054ebefa@mail.gmail.com> 1 sibling, 0 replies; 2+ messages in thread From: Avi Kivity @ 2008-08-11 14:15 UTC (permalink / raw) To: Gerd Hoffmann Cc: Jeremy Fitzhardinge, Glauber de Oliveira Costa, Marcelo Tosatti, Linux Kernel Mailing List, kvm-devel Gerd Hoffmann wrote: > Hi, > > >> However, the pvclock_clocksource_read() implementation is >> over-engineered, because it checks for an odd version and uses very >> strong rmb() barriers (which generates either an "lfence" or "lock add >> $0, (%esp)"). >> >> If we're happy to guarantee as an ABI issue that the record will never >> be updated cross-cpu, then we can make the barriers simply barrier() and >> just check for (src->version != dst->version). >> >> Is that OK with you, or do you want to leave open the possibility of >> doing cross-cpu time updates? >> > > Due to the TSC being involved here I don't expect cross-cpu time updates > will ever happen. IMHO it is fine to change that. > > I agree. And if we ever feel the need, we can allocate a feature bit for it. -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <5d6222a80808110718i6a600858v7bdb5e08054ebefa@mail.gmail.com>]
* Re: Use of barriers in pvclock ABI [not found] ` <5d6222a80808110718i6a600858v7bdb5e08054ebefa@mail.gmail.com> @ 2008-08-11 14:35 ` Avi Kivity 0 siblings, 0 replies; 2+ messages in thread From: Avi Kivity @ 2008-08-11 14:35 UTC (permalink / raw) To: Glauber Costa Cc: Gerd Hoffmann, Jeremy Fitzhardinge, Marcelo Tosatti, Linux Kernel Mailing List, kvm-devel Glauber Costa wrote: > On Mon, Aug 11, 2008 at 4:08 AM, Gerd Hoffmann <kraxel@redhat.com> wrote: > >> Hi, >> >> >>> However, the pvclock_clocksource_read() implementation is >>> over-engineered, because it checks for an odd version and uses very >>> strong rmb() barriers (which generates either an "lfence" or "lock add >>> $0, (%esp)"). >>> >>> If we're happy to guarantee as an ABI issue that the record will never >>> be updated cross-cpu, then we can make the barriers simply barrier() and >>> just check for (src->version != dst->version). >>> >>> Is that OK with you, or do you want to leave open the possibility of >>> doing cross-cpu time updates? >>> >> Due to the TSC being involved here I don't expect cross-cpu time updates >> will ever happen. IMHO it is fine to change that. >> > > Okay for guest vcpu, but what about physical cpus? > > > IIRC, the checks are there, and so strict, to account for the > possiblity of the vcpu to be migrated to another cpu in the middle of > the > Migration implies an smp barrier (but not a compiler barrier, of course). As to the the version number oddness check, I don't see how it can be necessary. -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-08-11 14:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <489CA3DA.1090400@goop.org>
[not found] ` <489FE56E.1080707@redhat.com>
2008-08-11 14:15 ` Use of barriers in pvclock ABI Avi Kivity
[not found] ` <5d6222a80808110718i6a600858v7bdb5e08054ebefa@mail.gmail.com>
2008-08-11 14:35 ` Avi Kivity
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox