Date: Fri, 01 Mar 2013 11:30:21 -0800 From: Alfred Perlstein <bright@mu.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-hackers <freebsd-hackers@FreeBSD.org> Subject: Re: memory allocation in spinlock context Message-ID: <513101CD.9060702@mu.org> In-Reply-To: <5130B224.8000600@FreeBSD.org> References: <5130B224.8000600@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?513101CD.9060702>