RE: [PATCH] Avoiding mmap fragmentation - clean rev

[Wolfgang Wander <wwc@rentec.com>]

I don't think that a truly random mmap/munmap works well the current
cache approach.  By filling any request into the first fitting hole
(and first being the first from the current cache pointer) all large
holes are going to be filled inefficiently.(*)

Ideally you would want to have a sorted list of holes and fit new
requests in there on a best match basis.  But this patch would be even
more complex than my one.

My goal was to place small requests close to the base while leaving
larger holes open as long as possible and far from the base. 2.4
kernels did this inadvertently by always starting to search from the
base, my patch starts searching from the base (upward or downward)
if the new request is known to fit between base and current cache
pointer, thus it maintains the 2.4 quality of mixing small and large
requests and maintains the huge speedups Ingo introduced with the
cache pointer.

One way or another I believe we need to address the issue of mixed
small and large map requests.  Either via my earlier approach or by
maintaining an index of holes.  If you feel the latter is needed I'd
certainly volunteer to provide a patch for this one as well...
Likewise if there are issues with my earlier patch, I hope I can
address them as well.

              Wolfgang



(*) Sidenote: in 2.4 (and my approach) large holes close to the base
              are still not going to be cluttered with smaller
              requests, however the large ones far from the base
              are going to stay there until they are needed.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>