Memory reserves or lack thereof

[Andre Oppermann]

On 12.11.2012 03:02, Adrian Chadd wrote:
> On 11 November 2012 13:40, Alan Cox <alan.l.cox at gmail.com> wrote:
>
>>
>> Agreed.  Once upon time, before SMPng, M_NOWAIT was rarely used.  It was
>> well understand that it should only be used by interrupt handlers.
>>
>> The trouble is that M_NOWAIT conflates two orthogonal things.  The obvious
>> being that the allocation shouldn't sleep.  The other being how far we're
>> willing to deplete the cache/free page queues.
>>
>> When fine-grained locking got sprinkled throughout the kernel, we all to
>> often found ourselves wanting to do allocations without the possibility of
>> blocking.  So, M_NOWAIT became commonplace, where it wasn't before.
>
> Well, what's the current set of best practices for allocating mbufs?

If an allocation is driven by user space then you can use M_WAITOK.

If an allocation is driven by the driver or kernel (callout and so on)
you do M_NOWAIT and handle a failure by trying again later either
directly by rescheduling the callout or by the upper layer retransmit
logic.

On top of that individual mbuf allocation or stitching mbufs and
clusters together manually is deprecated.  If every possible you
should use m_getm2().

> I don't mind going through ath(4) and net80211(4), looking to make it
> behave better with mbuf allocations. There's 49 M_NOWAIT's in net80211
> and 10 in ath(4). I wonder how many of them are synonyms with "don't
> fail allocating", too. Hm.

Mbuf allocations are normally allowed to fail without serious
after effects other than retransmits and some overall recovery
pain.

Only non-mbuf memory allocations for important structures or
state that can't be recreated on retransmit should dig into
reserves.  Normally this is a very rare case in network related
code.

-- 
Andre