From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 12:16:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C67D4E8 for ; Mon, 12 Nov 2012 12:16:43 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id F00008FC12 for ; Mon, 12 Nov 2012 12:16:42 +0000 (UTC) Received: (qmail 96184 invoked from network); 12 Nov 2012 13:51:05 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2012 13:51:05 -0000 Message-ID: <50A0E902.3080201@freebsd.org> Date: Mon, 12 Nov 2012 13:18:10 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Konstantin Belousov , "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 12:16:43 -0000 On 12.11.2012 03:02, Adrian Chadd wrote: > On 11 November 2012 13:40, Alan Cox 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