[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.059 / U:0.548 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site