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

From: "Thordur I. Bjornsson" <thib@foo.is>
To: mickey@lucifier.net
Cc: gnats@openbsd.org
Subject: Re: kernel/5761: improve kernel malloc
Date: Sat, 15 Mar 2008 15:24:24 +0100

 mickey@lucifier.net wrote on Mon 10.Mar'08 at 14:08:37 +0000
 
 > >Number:         5761
 > >Category:       kernel
 > >Synopsis:       improve kernel malloc
 > >Confidential:   yes
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    bugs
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          change-request
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Mar 10 14:20:02 GMT 2008
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     mickey
 > >Release:        4.3-current
 > >Organization:
 > net
 > >Environment:
 > 	System      : OpenBSD 4.3
 > >Description:
 > 	improve kernel malloc to escape the limitations
 > 	for the small objects allocations.
 > 	this is achieved by using pools for sub-page objects
 > 	in malloc while larger objects are handled same as before.
 > 	this reduces kernel memory fragmentation and allows
 > 	free memory reuse (which was not possible in old malloc).
 > 	as an additional benefit there is some speed improvement.
 > >How-To-Repeat:
 > 	n/a
 
 This doesnt work, atleast not on sparc64:
 root on sd0a swap on sd0b dump on sd0b
 pool_do_get: kmem4: items on itemlist, nitems 0
 panic: pool_do_get: nitems inconsistent
 kdb breakpoint at 138aa00
 Stopped at      Debugger+0x4:   nop
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
 PANIC!
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb{1}> tr
 pool_do_get(1881810, 20, deafbeef, 0, 4000bb8ccd0, 400) at
 pool_do_get+0x19c
 pool_get(1881810, 20, 0, 0, 0, 0) at pool_get+0x18
 malloc(10, 62, 1, 0, 0, 0) at malloc+0x320
 amap_swap_off(0, 4, 1, 0, 0, 20) at amap_swap_off+0x2b8
 amap_copy(4000bbaa260, 4000bba1e60, 1, 1, 43776000, 43776001) at
 amap_copy+0xfc
 
 udv_attach(4001a85bd10, 4000bbaa260, 0, 0, 0, e0018000) at
 udv_attach+0x5a8
 uvm_fault(e, 43776000, 0, 1, 1, 4001a85bc10) at uvm_fault+0x104
 data_access_fault(4001a85bed0, 30, 1601bc, 43776004, 43777e52, 800801)
 at data_
 access_fault+0xe8
 trapbase(26cfc0, fffffffffffbfb68, 0, 0, 0, 400) at trapbase+0x87b8
 ddb{1}>