Rafael Vanoni wrote: > Mike Shapiro wrote: >> >>> Hi Mike >>> >>> Thanks for looking at the webrev. Two quick questions before I push >>> the latest version: >>> >>> (1) wrt to gethrtime() during kmdb, I understand that mdb >>> implements it's own gethrtime(). But I'm not sure what to do within >>> mdb_get_lbolt in that situation. Should I just #ifdef _KMDB it out >>> ? >>> >>> (2) since this project is removing the lbolt variables, We've >>> received requests for a ::time dcmd that would return lbolt, >>> lbolt64 or gethrtime. What's your opinion on adding this new dcmd ? >>> >>> >>> Thanks, Rafael >> >> I don't understand-- what project is removing the lbolt variables? >> Your webrev is just about adding an mdb API. Also my point about >> kmdb's gethrtime() is that it just increments an integer and >> therefore you cannot backward compute an lbolt value from that. >> >> Can we start from the top: what problem are we trying to solve here? > > Sure, from a previous email: > >> One of the sub-projects of the tickless kernel effort is to decouple >> lbolt from the clock cyclic. To that end, and to address performance >> issues, the value provided by lbolt will be delivered by a function, >> and no longer a variable. The mod API references lbolt in a couple of >> places, I'm changing those in favor of the new function. > > I'm proposing that we create a new mdb routine - mdb_get_lbolt() - to > provide the value those consumers expect. > > I think you answered my first question. Since cyclics don't fire when > booted into kmdb, we can safely return a lbolt value of zero. I don't think that will work. The genunix module (for example) reads lbolt, and figures a delta for the last time a thread switched off the CPU...so using 0 for that won't work.
-Eric
