[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: [Fwd: Re: 3 connections as one]
From:       Matthew Dillon <dillon () apollo ! backplane ! com>
Date:       2008-06-26 20:12:41
Message-ID: 200806262012.m5QKCfgl022095 () apollo ! backplane ! com
[Download RAW message or body]


: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>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]