[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54908: kernel semi-lock-up
The following reply was made to PR kern/54908; it has been noted by GNATS.
From: Lars Reichardt <lars%paradoxon.info@localhost>
To: Andrew Doran <ad%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, martin%NetBSD.org@localhost
Subject: Re: kern/54908: kernel semi-lock-up
Date: Sat, 1 Feb 2020 08:59:12 +0100
On Fri, 31 Jan 2020 21:40:01 +0000 (UTC)
Andrew Doran <ad%netbsd.org@localhost> wrote:
> The following reply was made to PR kern/54908; it has been noted by
> From: Andrew Doran <ad%netbsd.org@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Subject: Re: kern/54908: kernel semi-lock-up
> Date: Fri, 31 Jan 2020 21:36:58 +0000
> On Fri, Jan 31, 2020 at 11:55:01AM +0000, Lars Reichardt wrote:
> > Maybe the rdaix radixtree allocations and reducing the kmem sizes
> > might have increased the memory footprint of the allocator just
> > enough to hit that wall.
> It's possible. I would be interested in buffer cache usage and
> excluding memory leaks first. "show all pools" would be useful here
> but it produces a lot of output.
Most pools allocate from the kmem arena the non exhaustive list of
exceptions I remember are:
- the buffer caches do have a special pool_allocator backend
those named kva-XXXX can be ignored they are used for allocating
virtual addresses within kmem.
kva-04096 is most likely of interest as most pool allocations seem to
have page_size sized poolpages and on systems with no direct map those
allocations are done via that pool.
Martin gave it try with the kmem arena limit raised
to 256mb but the system didn't boot which puzzels me as it seems to have
The reason for this is 128M for kmem isn't much for 2g physical memory
eg i386 raises this to about 320mb some others to 256mb.
Main Index |
Thread Index |