On Fri, Mar 1, 2013 at 2:50 PM, Andriy Gapon <a...@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-unsubscr...@freebsd.org" Thanks, -- Davide _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
