memory allocation in spinlock context

[Davide Italiano]

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

Thanks,

-- 
Davide