Hi Michael, Michael Pellon wrote: > My name is Michael Pellon and I am a PhD student in Computer Science > at the University of Vermont. Nice to meet you. :)
> Most of my experience is in low-level C/C++ developing inside the > linux kernel for Intel Xscale (ARM architecture microprocessors) but I > have had some experience working at higher-levels on linux device > drivers, etc. > > I would interested in helping with the clock driven lbolt migration > starting with putting together an extensive study of existing lbolt > consumers. Has anyone started work on this? Or is there other areas of > higher priority that deserve attention first? I had taken a look at this late last year. My first experiment involved changing the implementation of lbolt from a variable to a function...one that was essentially backed by gethrtime(). :) Those changes are present in the "tesla-gate" repository, which you can clone via: hg clone ssh://anon at hg.opensolaris.org/hg/tesla/tesla-gate If you want to dive in with this, it probably makes sense to create a new repository dedicated to the effort (I had originally used the generic "tesla-gate" repository when the project was in it's early stages). What do you think? That repository is pretty stale at this point, but at the time it built and functioned well. The biggest lingering concern with the implementation of this as is...is that the new "gethrtime()" backed implementation is certainly more involved (in terms of performance), than reading a kernel variable. :) So there are some lbolt consumers (like tcp) that depend on the cheapness of reading it. We had talked about enhancing what's implemented in the tesla-gate with a sort of "bi-modal" lbolt operation so that if the time source is being read frequently a cyclic still fires to update it...but if a few firings of the cyclic happen without anybody reading it...it falls back to the gethrtime() implementation (and the cyclic is disabled).... -Eric
