From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 1 19:30:30 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36568573; Fri, 1 Mar 2013 19:30:30 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2697E1164; Fri, 1 Mar 2013 19:30:30 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id CFD431A3C3D; Fri, 1 Mar 2013 11:30:24 -0800 (PST) Message-ID: <513101CD.9060702@mu.org> Date: Fri, 01 Mar 2013 11:30:21 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: memory allocation in spinlock context References: <5130B224.8000600@FreeBSD.org> In-Reply-To: <5130B224.8000600@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers 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: Fri, 01 Mar 2013 19:30:30 -0000 On 3/1/13 5:50 AM, Andriy Gapon wrote: > I am trying to understand if it is possible to allow memory allocations (M_NOWAIT, > of course) in a spinlock context. > I do not see any obvious architectural obstacles. > But the fact that all of the uma locks, system map lock, object locks, page queue > locks and so on are regular mutexes makes it impossible to allocate memory without > violating the fundamental lock ordering rules. > > Could all of the above mentioned locks potentially be converted to spin mutexes? > (And that seems to be a large nasty change) > Are there any alternative possibilities? > > BTW, currently we have at least one place where a memory allocation of this kind > is done stealthily (and thus dangerously?). ACPI resume code must execute > AcpiLeaveSleepStatePrep with interrupts disabled and ACPICA code performs memory > allocations in that code path. Since the interrupts are disabled by means of > intr_disable(), witness(9) and similar are completely oblivious of the fact. > Typically the need for such a facility means that the locks are being held for too long. I think someone has suggested using a private allocator carving out of a pre-allocated space. Depending on the subsystem you are allocating for this may work for you. I am looking to do this for the kernel gzip routines so that we can do compressed kernel dumps as soon as I verify the bounds of the gzip allocations. -Alfred