Date: Fri, 1 Mar 2013 15:36:05 +0100 From: Davide Italiano <davide@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: memory allocation in spinlock context Message-ID: <CACYV=-E_B2t9Z%2BLKfV4RkeY1WvkLmf1jf-N01=AXvfnKGaeiFg@mail.gmail.com> 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 Fri, Mar 1, 2013 at 2:50 PM, Andriy Gapon <avg@freebsd.org> 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) AFAIK they're suitable for particular uses and not in general. For example if the critical section is short, spinning rather than sleeping could avoid a potential context switches, increasing performances. OTOH has the disadvantage of wasting time that could be used in other activities. So, IMHO, if such a change need to be adopted, ti should be pondered/profiled more than a bit, and I doubt it could be used for the wide class of locks you mentioned. > Are there any alternative possibilities? > Is there anything that prevent you to drop the lock, perform the allocation in a reliable fashion (M_WAITOK) and try to reacquire the lock later on? > 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. > > -- > Andriy Gapon > _______________________________________________ > 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" Thanks, -- Davide
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-E_B2t9Z%2BLKfV4RkeY1WvkLmf1jf-N01=AXvfnKGaeiFg>