On Sat, Jun 28, 2008 at 02:14:05AM +1000, Simon Burge wrote: > > The attached patch is what I used. Any interest in cleaning this up > some more and committing it? I was thinking along the lines of maybe > kernel config options for enabling the existing histories (loanhist, > maphist, pdhist, and ubchist), but am still not sure of this. One > option is to leave them disabled and just include a commented-out > UVMHIST_ENABLE() with each one. Sounds good. I think having ways to enable one or another history section is good. > Somewhat related to this, I also found that using "call uvmhist_dump()" > from DDB was pretty hit-or-miss for two reasons: > > 1) We'd wedge at the splhigh() call in uvmhist_dump(), I assume > since interrupts were in a pretty broken state when DDB became > active. Locally I've commented out the splhigh()/splx() calls in > uvmhist_dump(). I'd also thought about adding a second parameter > to uvmhist_dump() to toggle the SPL dance. We probably want a separate entry point, for use in ddb. > 2) printf() would sometimes block because the KPRINTF_MUTEX_ENTER() > call would block. Whether this was the same issue as 1) or > because kprintf_slock was held I'm not sure. I just used a local > "printf_unlocked" to skip KPRINTF_MUTEX_ENTER(). One option is > to use DDB's db_printf() instead. As above. A "dumping to the capture app" call and a "ddb dump" call are good things to have. Internally, we probably want to pass around a printf routine, so that when we do the ddb dance, we can call db_printf(). > Any more thoughts on these two issues? > > Cheers, > Simon.
Attachment:
pgpuR8w7WdJZ5.pgp
Description: PGP signature