Subject: kernel map entry merging and PR 24039
To: NetBSD tech-kern <tech-kern@netbsd.org>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 02/04/2004 11:23:19
--Apple-Mail-45-978635380
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed
I noticed a short thread on this today, but I deleted the messages
before commenting (just too busy this morning).
Anyway, I think it's a pretty serious regression to disable kernel map
entry merging. A highly fragmented map is going to have a negative
impact on performance. (FWIW, I do think it would be cool if we had a
Solaris-like vmem, but I don't think it's necessary to solve this
problem.)
So, in reference to this commit to uvm_map.c:
----------------------------
revision 1.153
date: 2004/01/29 12:06:02; author: yamt; state: Exp; lines: +382 -98
- split uvm_map() into two functions for the followings.
- for in-kernel maps, disable map entry merging so that
unmap operations won't block. (workaround for PR/24039)
- for in-kernel maps, allocate kva for vm_map_entry from
the map itsself and eliminate MAX_KMAPENT and
uvm_map_entry_kmem_pool.
----------------------------
Instead of disabling entry merging for kernel maps, how about the
following:
* For every kernel map entry that would be merged and freed,
merge it, but instead of freeing the map entry, hang it off
a free list for that map.
* If, when unmapping, you need to allocate a new map entry because
of a split, pull an entry off that free list.
* Don't use those map entries on the free list for anything other
than the unmap-split case.
I guess the only issue then is to determine when free list entries can
be freed back when a split is not required on unmap.
Anyway, I think this, or some variation of this, could solve the
problem and still let us have map entry merging for kernel maps.
-- Jason R. Thorpe <thorpej@wasabisystems.com>
--Apple-Mail-45-978635380
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFAIUanOpVKkaBm8XkRAtVdAJsFHrGlIEjDdeykIVB+vzr4zOh9cgCfQrld
bZOXNjTqKH1ZXnIy8jbFpf8=
=ongJ
-----END PGP SIGNATURE-----
--Apple-Mail-45-978635380--