:All these per-subsystem free-lists are making me nervous in both
:complexity and wasted code...
:Ok, instead of keeping all these per-subsystem free-lists here's what
:we do:
:In kern_malloc:free() right at the point of
:  if (size > MAXALLOCSAVE) we check if we have Giant or not.
:    if we do not then we simply queue the memory
:    however, if we do then we call into kmem_free with all the queued memory.
:This ought to solve the issue without making us keep all these
:per-cpu caches.

    Hmm.  I don't like generalizing it to that extent.  What if we simply
    assert that Giant is held if size > MAXALLOCSAVE in free()?  i.e. for
    the moment we require that any 'large allocations' use Giant.  Then 
    we can freely use free() to free smaller allocations without Giant.

    There are three other problems: (1) malloc() itself will call kmem_malloc()
    even if M_NOWAIT is passed, so we can't optimize malloc()-without-giant
    unless we add a new flag to deal with this situation.  

    And, (2) we have a single mutex, malloc_mtx.  This is Bosko's code so
    I am adding him to the To: list.  Bosko, it looks like with a simple
    cleanup to the msleep() call we can use a pool lock instead of malloc_mtx,
    which would give us the ability to lock malloc() on a bucket-by-bucket
    basis.  The addition of a another malloc flag will allow us to tell
    malloc() to return NULL if it can't do the operation with its own mutex.

    And, (3) we wind up getting and releasing two mutexes instead of one
    in the code I was originally refering to, because setsid() already gets
    an SX lock and I was just going to fold the free list into that.  Still,
    I don't mind doing it via malloc().

    What do people think?

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

:By the way, since "MAXALLOCSAVE" is some multiple of PAGE_SIZE, we
:really don't have to worry about it when freeing small structures
:although that puts evilness into malloc(9) consumers.
:Can you please consider that instead of continueing down this path
:of per-subsystem caches?
:-Alfred Perlstein [[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to