[lkml]   [2002]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Scalability problem (kmap_lock) with -aa kernels
    On Wed, 20 Mar 2002, Andrea Arcangeli wrote:
    > On Wed, Mar 20, 2002 at 08:14:31AM -0800, Martin J. Bligh wrote:

    > > Looking at the code for map_new_virtual, note that we start at where
    > > we left off before: last_pkmap_nr = (last_pkmap_nr + 1) & LAST_PKMAP_MASK;
    > > So we don't scan the whole array every time - we just walk through it
    > > one step (on most instances, assuming most of pool is short term use).
    > and if we didn't find anything we call flush_all_zero_pkmaps that does a
    > whole O(N) scan on the pool to try to release the entries that aren't
    > pinned and then we try again. In short if we increase the pool size, we
    > linearly increase the time we spend on it (actually more than linearly
    > because we'll run out of l1/l2/l3 while the pool size increases)

    That suggests we'd want a pool size of 1 to be O(1) buzzword
    compliant ;)

    Going for a smaller pool just doesn't make sense if you want
    the mappings to be cached, it could even result in more processes
    _sleeping_ on kmap entries to be freed.

    Please make a choice, do you want kmaps to be cached or would
    you be content to have just cpu-local or maybe process-local
    kmaps and get rid of the global kmap pool ?


    Bravely reimplemented by the knights who say "NIH".

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:25    [W:0.022 / U:4.388 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site