The following reply was made to PR port-i386/34186; it has been noted by GNATS.

From: Wolfgang.Stukenbrock@nagler-company.com
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-i386/34186 (msgbuf allocation)
Date: Tue,  5 Dec 2006 12:46:11 +0100

 Hi, once again.
 
 I don't know the value of VM_PHYSSEG_MAX, but you should keep in mind that 
 there is (or will be) a static array in the kernel with MSGBUF_MAX_SEG elements.
 If you set this constant to a large number, you are gooing to wast a lot of 
 memory just for setting up the message buffer.
 
 The maximum number ever needed may be calculated from MSGBUFSIZE and the size 
 of a physical memory page. This number of entries are required if all of 
 the "last segments" that are selected for the message buffer in the phys-mem 
 list contains only one page till the message buffer is setup completely.
 It will make no sence to set this constant to a larger number.
 
 My plan was to allow to specify a large constant for hardware that needs it via 
 kernel configuration and setup a default (2 in this case) that will meet the 
 requirements of most systems. Most systems will never use more as one entry for 
 the message buffer at all. Perhaps it would be usefull to document this new 
 kernel option in the GENERIC configuration file by adding a line as a comment.
 
 W. Stukenbrock
 
 Quoting Pavel Cahyna <pavel@NetBSD.org>:
 
 > The following reply was made to PR port-i386/34186; it has been noted by
 > GNATS.
 > 
 > From: Pavel Cahyna <pavel@NetBSD.org>
 > To: Blair Sadewitz <blair.sadewitz@gmail.com>
 > Cc: gnats-bugs@netbsd.org
 > Subject: Re: port-i386/34186 (msgbuf allocation)
 > Date: Tue, 5 Dec 2006 09:04:31 +0000
 > 
 >  On Sun, Dec 03, 2006 at 11:39:16AM -0500, Blair Sadewitz wrote:
 >  > The msgbuf allocation fix seems to work as intended when
 >  > MSGBUF_MAX_SEG is defined to a larger value.  If it is approved by
 >  > christos et. al., I'd appreciate it being added to i386 and amd64.
 >  > 
 >  > Should MSGBUFSIZE now be derived from MSGBUF_MAX_SEG to avoid
 >  > redundancy?  Specifying both seems overly complex.
 >  
 >  No, because the size of message buffer has no simple relationship to the
 >  number of segments used.
 >  
 >  There is VM_PHYSSEG_MAX constant which is the maximum number of physical
 > memory
 >  segments. It should be used instead of MSGBUF_MAX_SEG imo.
 >  
 >