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. My second question was to try to address the need for getting a time reference through mdb. Currently, we could simply print lbolt. But that will no longer be possible because of our changes, so we'd like to offer a ::time dcmd to fill in this gap. Does that make sense ? Thanks, Rafael
