linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* /proc/<n>/maps growing...
@ 2001-08-06  6:41 David Luyer
  2001-08-06  7:43 ` Chris Wedgwood
                   ` (2 more replies)
  0 siblings, 3 replies; 29+ messages in thread
From: David Luyer @ 2001-08-06  6:41 UTC (permalink / raw)
  To: linux-kernel


This is from evolution-mail.

It _looks_ like lots of contiguous, equal protection mappings which
should be
merged:


40f00000-40f08000 rw-p 000bf000 00:00 0
40f08000-40f0e000 rw-p 000c7000 00:00 0
[... 37 lines deleted ...]
40f5e000-40f60000 rw-p 0011d000 00:00 0
40f60000-40f63000 rw-p 0011f000 00:00 0
40f63000-40f64000 rw-p 00000000 00:00 0
40f64000-40f65000 rw-p 00001000 00:00 0
[... 26 lines deleted ...]
40f88000-40f89000 rw-p 00025000 00:00 0
40f89000-40f8a000 rw-p 00026000 00:00 0
40f8a000-40f8b000 rw-p 00149000 00:00 0
40f8b000-40f8c000 rw-p 0014a000 00:00 0
[... 99 lines deleted ...]
40ff7000-40ff8000 rw-p 001b6000 00:00 0
40ff8000-40ff9000 rw-p 001b7000 00:00 0
40ff9000-40ffa000 rw-p 001b8000 00:00 0
40ffa000-41000000 ---p 001b9000 00:00 0
41000000-41026000 r--s 00000000 00:03 110985227  /SYSV00000000 (deleted)
41026000-41044000 r--s 00000000 00:03 111018010  /SYSV00000000 (deleted)
41100000-41101000 rw-p 000bc000 00:00 0
41101000-41102000 rw-p 00000000 00:00 0
41102000-41103000 rw-p 00001000 00:00 0
41103000-41104000 rw-p 00002000 00:00 0
41104000-41105000 rw-p 00003000 00:00 0
41105000-41108000 ---p 00004000 00:00 0
41108000-41200000 ---p 000c4000 00:00 0

and then a bit later:

[... much deleted ...]
40ff7000-40ff8000 rw-p 001b6000 00:00 0
40ff8000-40ff9000 rw-p 001b7000 00:00 0
40ff9000-40ffa000 rw-p 00000000 00:00 0
40ffa000-40ffc000 rw-p 00001000 00:00 0
40ffc000-40ffd000 rw-p 00000000 00:00 0
40ffd000-40ffe000 rw-p 001bc000 00:00 0
40ffe000-40fff000 rw-p 001bd000 00:00 0
40fff000-41000000 rw-p 001be000 00:00 0
41000000-41026000 r--s 00000000 00:03 110985227  /SYSV00000000 (deleted)
41026000-41044000 r--s 00000000 00:03 111018010  /SYSV00000000 (deleted)
41100000-41101000 rw-p 000bc000 00:00 0
41101000-41102000 rw-p 00000000 00:00 0
41102000-41103000 rw-p 00001000 00:00 0
41103000-41104000 rw-p 00002000 00:00 0
41104000-41105000 rw-p 00003000 00:00 0
41105000-41106000 rw-p 00004000 00:00 0
41106000-41107000 rw-p 00005000 00:00 0
41107000-41108000 rw-p 00006000 00:00 0
41108000-41109000 rw-p 000c4000 00:00 0
41109000-4110a000 rw-p 000c5000 00:00 0
4110a000-4110c000 rw-p 000c6000 00:00 0
4110c000-4110d000 rw-p 000c8000 00:00 0
4110d000-4110e000 rw-p 000c9000 00:00 0
4110e000-4110f000 rw-p 000ca000 00:00 0
4110f000-41110000 rw-p 000cb000 00:00 0
41110000-41112000 rw-p 000cc000 00:00 0
41112000-41113000 rw-p 000ce000 00:00 0
41113000-41115000 rw-p 000cf000 00:00 0
41115000-41200000 ---p 000d1000 00:00 0

So the maps are slowly splitting up even though the permissions are the
same.

It seems to keep growing over time but Evolution isn't 100% stable yet
so it
crashes for no apparent reason every 6 hours or so.. unless that could
be when
it hits some 'limit' on the number of mappings allowed? 
-- 
David Luyer                                     Phone:   +61 3 9674 7525
Engineering Projects Manager   P A C I F I C    Fax:     +61 3 9699 8693
Pacific Internet (Australia)  I N T E R N E T   Mobile:  +61 4 1111 2983
http://www.pacific.net.au/                      NASDAQ:  PCNTF

^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: /proc/<n>/maps growing...
@ 2001-08-07  3:46 Rick Hohensee
  0 siblings, 0 replies; 29+ messages in thread
From: Rick Hohensee @ 2001-08-07  3:46 UTC (permalink / raw)
  To: linux-kernel

>> I believe the best way is to allocate always the new vma, and to hide
>> the merging into the lowlevel of a new insert_vm_struct (with a special
>> function ala merge_segments that we can share with mprotect like in
>2.2).
>

Torvalds
>Oh, and THAT is going to speed things up?
>
>Hint: the merging actually happens at a fairly high percentage for the
>common cases. We win more by walking the tree twice and avoiding the

BROWNNOSE
No, I have nothing to say about malloc/mmap/etc. I just want to add some
balancing positiveness to offset my usual polemics. Torvalds harps on
optimizing for the common case all the time. This little voice with a
faint scandanavian accent in the back of my head keeps saying "optimize
for the common case". It is a wise little voice. The common case is
usually beyond the ken of a compiler, it's something a human has to
know, it works, can pay off huge, and works with anything from assembly
to Bash. 
END BROWNNOSE   
RESUME FLAMEBAIT

Rick Hohensee
						www.clienux.com

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2001-09-03 15:44 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-06  6:41 /proc/<n>/maps growing David Luyer
2001-08-06  7:43 ` Chris Wedgwood
2001-08-06  8:59 ` Andrea Arcangeli
2001-08-06 10:30   ` Jakub Jelinek
2001-08-06 10:49     ` Andrea Arcangeli
2001-08-06 11:01       ` Jakub Jelinek
2001-08-06 11:25         ` Andrea Arcangeli
2001-08-06 17:17         ` Linus Torvalds
2001-08-06 17:26           ` Alan Cox
2001-08-06 22:55             ` Chris Wedgwood
2001-08-06 11:16       ` Jakub Jelinek
2001-08-06 17:18       ` Linus Torvalds
2001-08-06  9:20 ` David S. Miller
2001-08-06  9:46   ` Chris Wedgwood
2001-08-06 10:57   ` Andrea Arcangeli
2001-08-06 12:26     ` Chris Wedgwood
2001-08-06 12:36       ` Andrea Arcangeli
2001-08-06 12:45         ` Chris Wedgwood
2001-08-06 12:50           ` Andrea Arcangeli
2001-08-06 13:06           ` David S. Miller
2001-08-06 13:29             ` Andrea Arcangeli
2001-08-06 17:27               ` Linus Torvalds
2001-09-03 15:44                 ` mmap-rb-7 [was Re: /proc/<n>/maps growing...] Andrea Arcangeli
2001-08-06 17:20         ` /proc/<n>/maps growing Linus Torvalds
2001-08-07  2:24           ` David Luyer
2001-08-06 17:46         ` Anton Altaparmakov
2001-08-06 16:12   ` Rik van Riel
2001-08-06 17:46     ` Linus Torvalds
2001-08-07  3:46 Rick Hohensee

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).