Locking a file backed mdconfig into memory
John Baldwin
jhb at freebsd.org
Fri Jun 4 20:21:24 UTC 2010
On Friday 04 June 2010 1:58:13 pm Alan Cox wrote:
> Matthew D Fleming wrote:
> > On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote:
> >
> >> Hmmm, I would just try increasing NKPT then. You might have to poke
> >> around in sys/amd64 to see what the default size is and how to tune
> >> it.
> >>
> >
> > When Isilon did the stable/7 merge and amd64 default NKPT changed from
> > 240 to 32 amd64 started having weird pmap issues during boot. At panic
> > time the stack wasn't very useful, and I didn't finish debugging the
> > issue since eventually I just had to get something working. We just
> > reverted NKPT to 240 and it worked for us. I didn't see an anything in
> > optsions.amd64 so I hard-coded it in amd64/include/pmap.h.
> >
> > Supposedly amd64 can deal with a small NKPT and grow dynamically, but it
> > didn't seem to work for us. :-( Perhaps when we do the next merge
> > project I'll have a few days to devote to debugging the root cause.
> >
>
> NKPT controls the number of page table pages that are initially
> allocated at the bottom of the top 2GB of the kernel address space.
> However, the vast majority of the kernel address space, 510GB in FreeBSD
> >=7.3, is below these page table pages. The page table pages for this
> region are dynamically allocated as needed.
>
> If you're booting a kernel and modules greater than 64GB in size, then I
> can certainly see why you would need to increase NKPT.
64GB seems like a lot of address space, I would not expect that to be
completely used by kernel and modules. I think earlier in the thread someone
said they had problems with a "mere" 295MB mfsroot.
> John, is there some way to know at boot time how big the kernel and
> modules were? Then, we could probably eliminate NKPT.
I think the loader knows, so it could pass that info to the kernel.
--
John Baldwin
More information about the freebsd-stable
mailing list