Date: Thu, 26 Jun 2008 13:12:41 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-hackers@freebsd.org, martes@mgwigglesworth.com, Luiz Otavio O Souza <luiz@aonet.com.br> Subject: Re: [Fwd: Re: 3 connections as one] Message-ID: <200806262012.m5QKCfgl022095@apollo.backplane.com> References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> <001901c8d78d$8180c680$5e00a8c0@note4c47> <200806261653.m5QGrasG020325@apollo.backplane.com> <4863CCF4.3000200@elischer.org> <200806261742.m5QHgbWo020788@apollo.backplane.com> <4863F3F9.6020206@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:what can I say without degenerating into a dogfight? :The code is designed to copy with failure to allocate.. the error will :propogate up.. : :not much is allocated once you have it set up. Well, not really trying to start a fight but unless the initialization code that sets this stuff up retries on ENOMEM, don't you risk load on the machine creating a situation where M_NOWAIT can return NULL under normal operation and cause a one-time initialization to basically fail? That doesn't sound good to me. I've noticed the same thing with many driver's softc allocations. A lot of them use M_NOWAIT but clearly do not handle a temporary allocation failure. They may not crash, but they won't initialize either. The user expectation is for the driver to only fail to initialize if something serious has occured. DragonFly is a bit more sensitive then FreeBSD. Maybe M_NOWAIT allocations on FreeBSD have no chance of failing unless the system is actually out of memory. But on DFly anything that would cause a thread switch during the allocation will fail if M_NOWAIT is specified. -Matt Matthew Dillon <dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806262012.m5QKCfgl022095>