cvs commit: src/sys/vm uma_int.h

David O'Brien obrien at FreeBSD.ORG
Mon Jun 20 17:08:11 GMT 2005


On Mon, Jun 20, 2005 at 12:45:37PM +0300, Dmitry Pryanishnikov wrote:
> 
> Hello!
> 
> >Date:      Sun, 19 Jun 2005 11:11:00 +0300
> >From:      Giorgos Keramidas <keramida at ceid.upatras.gr>
> >To:        Wilko Bulte <wb at freebie.xs4all.nl>
> >Cc:        src-committers at FreeBSD.ORG, Alan Cox <alc at FreeBSD.ORG>, 
> >           cvs-src at FreeBSD.ORG, Alan Cox <alc at cs.rice.edu>, 
> >           cvs-all at FreeBSD.ORG, David O'Brien <obrien at FreeBSD.ORG>
> >
> >On 2005-06-17 21:24, Wilko Bulte <wb at freebie.xs4all.nl> wrote:
> >> On Fri, Jun 17, 2005 at 12:46:58PM -0500, Alan Cox wrote..
> >> >
> >> > I recall that 42 was the minimum to fix Eric's panic.  I chose 48 so
> >>
> >Of course it should be 42...
> >
> >So, who's going to commit this?
> >
> >%
> >% -#define UMA_BOOT_PAGES		48	/* Pages allocated for 
> >startup % +#define UMA_BOOT_PAGES		42	/* DON'T PANIC */
> 
>  Is it possible to tune this (or ideally, autotune) from the loader (or
>  during the initialization of the kernel itself)?

I'm not sure what advantage there is in allowing this to be tuned from
the loader.  What we need is to have the kernel itself auto-tune, or we
need a much better failure mode.  We should have failed much more
gracefully than panics that seemed to have no rhyme or reason as to the
reason.  Meaning the "smoking gun" commit wasn't the same for everyone
that hit the panic, nor was the back trace seemingly related to the "bad"
commit.

It looks like there was an attempt at a better failure mode:
    sys/vm/uma_core.c:911:  panic("UMA: Increase UMA_BOOT_PAGES");
but it wasn't extensive enough and was being triggered in this case.

-- 
-- David  (obrien at FreeBSD.org)


More information about the cvs-src mailing list