hi,

> On Wed, Feb 04, 2004 at 06:34:06AM +0100, Quentin Garnier wrote:
> > Le Tue, 3 Feb 2004 21:57:34 -0500
> > Andrew Brown a ecrit :
> > > it used to be the case that my (i386/1.6ZI) kernel_map had around 20
> > > or so entries (as indicated by "pmap 0 | wc -l" (yes, i know that's
> > > off by one)).  nowadays, my kernel loiters between ~2600 and ~2900,
> > > most of which look like they ought to be mergeable.  that's a large
> > > change.
> > > 
> > > is anyone else seeing this behavior?
> > 
> > Is it related to the fact that it gets very hard to allocate large chunks
> > of device memory, such as the kind of blocks umass(4) uses?
> 
> I think so, yes.

are you talking about memory or kva fragmentation?
i think they're not directly related to map entry merging.

> I am starting to seriously question the validity of
> disabling kernel map merging as a workaround to a single bug that most
> users probably never saw... :-/

a single bug is enough, IMHO.
if there's a better solution, i'd happily re-enable merging.

however, i agree that it isn't pretty to have ton of entries.
given most of in-kernel entries are of the same size,
i'm wondering about gathering them into large chunks.
(maybe it'd be better to have a framework like solaris vmem?)

YAMAMOTO Takashi