On Wed, Feb 04, 2004 at 09:03:59PM +0900, YAMAMOTO Takashi wrote:
>> 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 don't think they are either.  map entry merging only results in less
entries, not less memory usage.  unless you consider the indirect
effect of less entries overall meaning that you need to waste less
memory to keep track of how much memory you're using.

right now i'm at 2600 map entries.  on my i386, struct vm_map_entry is
88 bytes, so that's 228800 bytes (though are they really allocated
with that granularity?).  i used to be around 20-30 entries, which
amounts to maybe 3000 bytes.  that means i'm currently "wasting" 220k
of kva to keep track of the other stuff i would be doing anyway.

>> 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.

let's find the bug then.  in brief, the theory is that uvm_unmap()
sometimes sleeps when it should not?

>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?)

a better allocator won't have the same effect, it will just be
different.  the allocator is the same whether you merge or don't
merge.  the only difference is the overhead of allocating when you
need less map entries (there are less map entries to scan, and less
memory consumed by them).  in the end, the map entries will still mean
the same thing.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."