Well, if UMA is going to eventually remove kmem_map and
just use kernel_map (or vise-versa), then the issue comes
down to why kernel_map->lock is lockmgr lock in the
first place, instead of a mutex.
I think the reason is historical. Basically kernel_map was
originally a struct vm_map just like the vm_map's used
everywhere else in the system. But then all sorts of
problems cropped up and it had to be special cased...
but what REALLY should have happened is that we should
have stopped using the stupid struct lock for kernel_map.
Perhaps for the case of kernel_map and only kernel_map,
the 'lock' field should be ignored entirely (1) and a
kernel_map_mtx (a global mutex) be used instead.
Then we don't have to screw around with it at all, we would
not have to worry about 'blocking' situations in the sturct lock
sense, only in the mtx_lock() sense.
Am I making any sense here?
-
note (1): In fact, the kernel_map->lock should be initialized such
that the system panics if anyone tries to play with it.
-Matt
:Started looking at making malloc mpsafe.
:
:First issue I came across was this brokenish code in
:uma_core.c:page_alloc():
:
: if (lockstatus(&kernel_map->lock, NULL)) {
: *pflag = UMA_SLAB_KMEM;
: p = (void *) kmem_malloc(kmem_map, bytes, wait);
: } else {
: *pflag = UMA_SLAB_KMAP;
: p = (void *) kmem_alloc(kernel_map, bytes);
: }
:
:using lockstatus won't work for smp.
:
:I think a solution is to do a trylock on the kmem_map, then have
:kmem_malloc either recurse on the lock, or take a flag to tell it
:not to bother locking.
:
:?
:--
:-Alfred Perlstein [[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
