tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Disabling histories in uvmhist.

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

Home | Main Index | Thread Index | Old Index