Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Dec 2001 10:24:23 +0300 (MSK)
From:      Varshavchick Alexander <alex@metrocom.ru>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: 4G phisical memory kernel trap
Message-ID:  <Pine.GSO.4.21.0112061018260.9266-100000@apache.metrocom.ru>
In-Reply-To: <3C0F09EB.6AD237E8@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Dec 2001, Terry Lambert wrote:

> > Alexander,
> > I had experienced this problem before. It is most likely that you are running
> > out of page table pages. Try changing NKPT in /sys/i386/include/pmap.h to 64.
> > That worked for me.
> > 
> > tim
> > 
> > On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote:
> Date: Wed, 05 Dec 2001 22:02:19 -0800
> From: Terry Lambert <tlambert2@mindspring.com>
> To: Tim Wiess <twiess@ahaza.com>
> Cc: Varshavchick Alexander <alex@metrocom.ru>, freebsd-hackers@FreeBSD.ORG
> Subject: Re: 4G phisical memory kernel trap
> 
> Tim Wiess wrote:
> > 
> > > Hi,
> > >
> > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps
> > > while booting - "fatal trap 12 page fault". With less than 4G memory the
> > > server is working good.
> 
> He will still se problems under load, if he does this.  In particular,
> it will lead to panics under load.
> 
> 
> The primary problem with using 4G is that the KVA space is too
> small to use that much memory reasonably, because of the swap maps
> that get created in /sys/i386/i386/machdep.c, which are scaled to
> 3 times the KVA space.
> 
> In general, the FreeBSD design was to support sparse memory maps,
> where the amount of physical RAM did not approach the limits of
> the address space.
> 
> I worked around this once by changing the calculation significantly,
> so that there was not an overallocation of the mapping tables.
> 
> To be able to put this extra memory to profitable use, you will
> need to be able to allocate kernel structures, such as sockets,
> mbufs, and open file table entries, tcpcb's and inpcb's in it.
> 
> For this to work, you really MUST address the machdep.c problems.

So how can it be done, are there any patches for machdep.c, or is it
solved in 4.4-stable kernel?

> 
> I also suggest increasing the KVA space from 3G to 4G.
> 

You mean setting KVA_SPACE option in kernel config?

> Another sugestion is that you should use 4M pages for most of
> this memory, if you can figure out how to do it (it's not hard,
> but there is some minor intelligence required, since you will
> end up getting more trap 12 faults if you aren't careful).  The
> mere acto of going to 4M pages will save you 4K per 4M of pages
> times how many pages you have, or ~4M.  You will also get a 4-6%
> performance increase, overall, depending on usage patterns.
> 

I'm afraid I can have problems figuring this thing out, can you please
give guidelines here?

> I really should write an article for Daemon New on the FreeBSD
> startup process at boot time, to fill in the gaps behind Matt
> Dillon's articles on FreeBSD VM after it has been started up.
> I will start work on one.
> 

It will be great!

Alexander Varshavchick, Metrocom Joint Stock Company
Phone: (812)118-3322, 118-3115(fax)




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.21.0112061018260.9266-100000>