NetBSD Problem Report #59897

From www@netbsd.org  Thu Jan  8 11:20:59 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 0FA071A923C
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  8 Jan 2026 11:20:59 +0000 (UTC)
Message-Id: <20260108112058.1D0421A923F@mollari.NetBSD.org>
Date: Thu,  8 Jan 2026 11:20:58 +0000 (UTC)
From: cryintothebluesky@gmail.com
Reply-To: cryintothebluesky@gmail.com
To: gnats-bugs@NetBSD.org
Subject: NetBSD virtual memory subsystem should support larger page sizes
X-Send-Pr-Version: www-1.0
X-From4GNATS: "cryintothebluesky@gmail.com via gnats" <gnats-admin@NetBSD.org>

>Number:         59897
>Category:       kern
>Synopsis:       NetBSD virtual memory subsystem should support larger page sizes
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 08 11:25:00 +0000 2026
>Last-Modified:  Thu Jan 08 14:35:01 +0000 2026
>Originator:     Sad Clouds
>Release:        10.1_STABLE
>Organization:
>Environment:
>Description:
Linux, FreeBSD and Solaris virtual memory subsystems implement support for multiple pages sizes via various non-portable APIs. Unfortunately OpenBSD and NetBSD seem to be lagging behind in this area.

I'm not a kernel developer, however I think NetBSD can use large pages internally within the kernel address space, but there is absolutely no such facility exposed to the user space.

There is a significant performance advantage associated with large pages for memory intensive applications. For example FreeBSD-15 on amd64 can use 4KiB, 2MiB, and 1GiB page sizes via shm_create_largepage(). My own testing shows how much difference this can make when allocating and page faulting a 64 GiB memory segment:

4KiB pages: 38557 msec to prefault 64 GiB
2MiB pages: 299 msec to prefault 64 GiB

That is about 128 times quicker when using 2MiB page sizes.

Linux and Solaris show smaller performance differences between different page sizes but still significant enough to make this feature worthwhile.

FreeBSD shm_create_largepage() API is not the best design and a bit awkward to use. Extensions to mmap() to select specific page sizes would be a better design for NetBSD.
>How-To-Repeat:

>Fix:

>Audit-Trail:
From: Sad Clouds <cryintothebluesky@gmail.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org
Subject: Re: kern/59897: NetBSD virtual memory subsystem should support
 larger page sizes
Date: Thu, 8 Jan 2026 14:32:18 +0000

 The time difference I recorded previously looked too good to be true.
 It may have been a runtime FreeBSD kernel quirk, after I rebooted the
 system and repeated the same test I got more reasonable metrics.

 On amd64 FreeBSD-15 going from 4 KiB to 2 MiB pages results in around
 2.7X speed up.

 On sparc Solaris-11 going from 8 KiB to 4 MiB pages results in around
 3.3X speed up.

 So I think it is reasonable to expect NetBSD to get around 3X speed up
 with larger page sizes. I'm not sure how much effort it would be to
 make the required changes, but it would be good to look into
 implementing Solaris getpagesizes() function and may be some form of
 static preallocation for a pool of large pages to be requested via
 mmap()?

 In the future it may be worth implementing dynamic transparent pages.
 Solaris seems to do this by default and according to "pmap -sx" it
 tends to use 4 MiB pages on sparc. This feature is much more relevant
 now with modern hardware supporting GBs and TBs of memory.

Home	PR Database Search