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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
