[mdb-discuss] flag for post-mortem/in situ target

[Eric Saxe]

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

[mdb-discuss] flag for post-mortem/in situ target

[Eric Saxe]

Eric Saxe wrote:

 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.
I think this again highlights the need for (even with a tickless lbolt 
service) to have a reliable clock_t based reference time available...and 
this is true within the context of the debugger looking at a stopped 
kernel, and also to keep in crash dumps (more of a concern for savecore 
-L since figuring panic_lbolt while panicking is easy enough). It would 
be ideal to stash this in a demand based fashion, so updating something 
either when savecore -L is run, or when making the transition into the 
debugger. Then perhaps that thing that is stashed could be what a ::time 
dcmd provides...

-Eric