Subject: Re: kernel map entry merging and PR 24039
To: YAMAMOTO Takashi <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 12/02/2004 22:28:45
On Thu, Dec 02, 2004 at 11:26:43PM +0900, YAMAMOTO Takashi wrote:
>> >can you explain what's an important difference? thanks.
>> using up memory is simply not the same as reserving it. reserved
>> memory can be used for something at a later point in time. used
>> memory cannot.
>memory used for map entries can be used for something else
>when it's no longer needed (ie. after the map is unmapped.)
well...that's true in either case.
>> imho, using 2000 instead of 200 (or even 20) map entries cannot be
>> considered a reaonable solution to any problem. unless the problem is
>> that you have too much ram. :)
>if you have only 20 entries and haven't seen the deadlock problem,
>it just means you're lucky enough.
>i don't think it's reasonable to rely on the pure luck at all.
i'm not sure it's luck...
>and of course, regardless of what pmap(1) shows, you always have
>>=1000 reserved entries.
i do? where?
the main point is that whether you merge or not, you can *always* get
into a situation where you need to allocate in order to de-allocate.
there's nothing stopping me from allocating three contiguous pages
(covered by one map entry) and then freeing the middle one when
there's no free memory left. not merging map entries when possible
simply makes this more likely, afaict.
otoh, using more map entries means more memory is consumed by map
entries, less is available for doing actual stuff, and probably has
other nasty side-effects like making searches for free space take
longer since the linked list is longer...
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."