NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

PR/57208 CVS commit: [netbsd-10] src/sys/kern



The following reply was made to PR kern/57208; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/57208 CVS commit: [netbsd-10] src/sys/kern
Date: Wed, 18 Oct 2023 15:03:12 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Oct 18 15:03:12 UTC 2023
 
 Modified Files:
 	src/sys/kern [netbsd-10]: subr_thmap.c
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #423):
 
 	sys/kern/subr_thmap.c: revision 1.14
 	sys/kern/subr_thmap.c: revision 1.15
 
 thmap(9): Test alloc failure, not THMAP_GETPTR failure.
 THMAP_GETPTR may return nonnull even though alloc returned zero.
 
 Note that this failure branch is not actually appropriate;
 thmap_create should not fail.  We really need to pass KM_SLEEP
 through in this call site even though there are other call sites for
 which KM_NOSLEEP is appropriate.
 
 Adapted from: https://github.com/rmind/thmap/pull/14
 PR kern/57666
 https://github.com/rmind/thmap/issues/13
 
 thmap(9): Preallocate GC list storage for thmap_del.
 thmap_del can't fail, and it is used in places in npf where sleeping
 is forbidden, so it can't rely on allocating memory either.
 Instead of having thmap_del allocate memory on the fly for each
 object to defer freeing until thmap_gc, arrange to have thmap(9)
 preallocate the same storage when allocating all the objects in the
 first place, with a GC header.
 
 This is suboptimal for memory usage, especially on insertion- and
 lookup-heavy but deletion-light workloads, but it's not clear rmind's
 alternative (https://github.com/rmind/thmap/tree/thmap_del_mem_fail)
 is ready to use yet, so we'll go with this for correctness.
 PR kern/57208
 
 https://github.com/rmind/npf/issues/129
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.12 -r1.12.4.1 src/sys/kern/subr_thmap.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 


Home | Main Index | Thread Index | Old Index