Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Feb 2003 12:20:53 -0400 (AST)
From:      The Hermit Hacker <scrappy@hub.org>
To:        David Schultz <dschultz@uclink.Berkeley.EDU>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: latest kernel issue ... or increased KVA_FILES ... ?
Message-ID:  <20030214121353.T76487@localhost>
In-Reply-To: <20030214115355.GA424@HAL9000.homeunix.com>
References:  <20030214065945.L76487@localhost> <20030214115355.GA424@HAL9000.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Feb 2003, David Schultz wrote:

> Thus spake The Hermit Hacker <scrappy@hub.org>:
> >    I added 'options KVA_FILES=512' to my kernel config last night, and
> > rebooted with the new settings, and fear I may have either error'd with
> > it, or just am getting hit by a bug in the latest code ...
> >
> >   First "stupid question", if I increase KVA_FILES, does that cause any
> > changes to 'world' that requires me to do an installworld right away for
> > thigns to work?  I upgraded the source from Feb 1st -> Feb 13th, so I only
> > did an installkernel, rebooted, and was going to do the installworld
> > after, except that after reboot, two daemons that use threads wouldn't
> > run, giving errors to /var/log/messages of:
> >
> > Feb 13 23:55:35 venus /kernel: pid 901 (nsd8x), uid 65534: exited on signal 6
>
> I assume you mean KVA_PAGES.  Changing that value changes how the
> 4 GB virtual address space is split between the kernel and
> userland applications.  The kernel occupies the upper end of the
> space, and the user application's stack (which grows downwards on
> most architectures) resides just below that.  If you set aside
> more of the virtual address space for the kernel, the start of the
> stack is lower and applications have a smaller space.

When Tor suggested changing this to me, he mentioned "This reduces the
address space available for userland processes, but very few applications
need more than 1 GB for data in a single process." ... now, if I'm
understanding this correctly, if I set it to 512, a single process won't
be able to exceed 2GB (*very* unlikely), but what happens if it does?
Does the process just crash, but the system remains running?

> Pthreads in 4-STABLE uses the start of the main stack as a basis
> for determining where to put stacks for individual threads that
> are spawned.  The value of KVA_PAGES used to be statically
> compiled into pthreads, so you would have to recompile libc every
> time you changed KVA_PAGES.  Peter Wemm tried to fix this some
> time ago by reading the value from sysctl instead, but his fix is
> incomplete.  The patch in the following PR has been verified (not
> by me) to fix the problem.  Hopefully it has not been subject to
> bit rot over the last few months.

'K, but as long as I install/upgrade both kernel and world at the same
time, there won't be a problem, right ... ?

> >   Similar was happening to the mysqld daemon ...
>
> Random naive question: Postgresql spawns separate processes
> instead of using threads, doesn't it?  How has that worked out,
> and is it expected to change?

Not expected to change, and works quite well ... there has been alot of
work to reduce the start time for the process(es), which used to be alot
of the complaints concerning 'seperate processes' ... there are ppl
talking about working towards the Apache2 model (I'm one of them) where
each process would still only handle one connection, but would be able to
offload some of the processing to other threads, so that they could work
in parrellel ...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030214121353.T76487>