This week I'm hoping to complete the coding changes to eliminate the lbolt dependency on clock().
The goal of the change is to eliminate the "lbolt" time source's dependency on the 100 Hz clock...which is necessary for a "tickless" architecture. This obviously isn't easy, as lbolt (and lbolt64) is used pervasively throughout the kernel. There are around 400 uses of lbolt alone in ON, and it's reasonable to expect that there are other non-DDI compliant drivers floating about that reference the variable. My first pass at this involves replacing "lbolt" the variable with "lbolt()" the function call (same for lbolt64). The implemenation of lbolt/lbolt64 will be backed with gethrtime()...and will essentially translate the reading of the TSC into a 10ms tick count. While the code changes to do this are straightforward enough (if not tedious), I have some concerns around both the performance and compatibility impacts of such a change. Even though lbolt is course resolution, it's very cheap to read (memory reference). TSC is cheap to read as well, so i'm hoping that this will be a reasonable replacement. As an experiment, I have a kernel undergoing performance testing right now that has tcp using a TSC backed lbolt implementation (since tcp is obviously performance critical and consumes lbolt fairly liberally in the "wire speed" code paths). We'll see how that shakes out. For the compatibility side of this, my hope is that the bulk of ON external drivers consume ddi_get_lbolt(9F) (or similar). If they don't, this change will be a forcing function, as drivers attempting to reference the lbolt symbol won't find it, and will refuse to load on a "tickless" kernel. I was thinking we could provide some simple tools (like a script based on nm that looks for driver dependencies on lbolt) to get the ball rolling, Also, well in advance of this integration a few "Heads up" type messages probably wouldn't hurt either. -Eric
