Re: /proc/<n>/maps getting _VERY_ long

[Linus Torvalds <torvalds@transmeta.com>]

In article <20010806010738.B11372@unthought.net> you write:
>> 
>> Linus took itout because it was quite complex and nobody seemed to have
>> cases that triggered it or made it useful
>
>What ??
>
>It was put back in because RH GCC-2.96 triggers this too.  There was a thread
>about this some months ago.

Strictly speaking, it wasn't put back. 

What recent kernels will do is merge a certain subset of mergeable
areas: this speeds up anonymous page allocation, whether by
mmap(MAP_ANONYMOYS) or by brk(). That subset was just made a bit larger
(and no, the subset hasn't been shrunk).

However, it doesn't merge in the generic case (it does not merge
mappings with backing store, for example), and it also does not merge
the case of the user actively changing the memory protections, for
example. 

So we certainly used to do more aggressive merging.

We could merge more, but I'm not interested in working around broken
applications. Right now we sanely merge the cases of consecutive
anonymous mmaps, but we do _not_ merge cases where the app plays silly
games, for example.

I'd like to know more than just the app that shows problems - I'd like
to know what it is doing.

		Linus