RE: [Linux-ia64] mmap and malloc questions on IA-64 linux

From: David Mosberger <davidm_at_napali.hpl.hp.com>
Date: 2002-08-06 06:31:00
>>>>> On Mon, 5 Aug 2002 08:40:17 -0700 , "Olivier, JeffreyX" <jeffreyx.olivier@intel.com> said:

  Jeff> Your suggestion that munmap() might fragment the map reminded
  Jeff> me of something else.  Upon receiving a write notice from
  Jeff> another node for a page, our system uses mprotect on the page
  Jeff> so that we can't write to it without causing a segmentation
  Jeff> fault.  Since we do this on a per-page basis, this is likely
  Jeff> the cause of the multiple mappings and since we are doing this
  Jeff> over such a large address space, it is likely that the linux
  Jeff> default of 65536 memory maps is the problem.  Does that seem
  Jeff> reasonable?

Yes, indeed.

  Jeff> I can see two possible solutions:

  Jeff> 1.  Develop an algorithm to efficiently combine memory
  Jeff> mappings with the same protections.  This would be fairly
  Jeff> straight forward for my program but for more sporadic memory
  Jeff> accesses, it might not work very well.

That's what the Linux kernel did up to the pre-2.4.0 series of
patches.  Then Linus ripped the merging logic out and replaced it with
something simpler.  The old merging logic had some nasty SMP issues,
IIRC.

It's something that should be discussed on the general linux-kernel
mailing list (linux-kernel@vger.kernel.org), as this is not specific
to ia64.

  Jeff> 2.  Change the default maximum number of mappings.  I noticed
  Jeff> a /proc/sys/vm/max_map_count variable.  Can this be increased
  Jeff> safely?

In the standard 2.4.18 kernel, MAX_MAP_COUNT is a hardcoded constant.
But in either case, AFAIK, the main reason for the existence of the
limit is to have (some) protection against denial-of-service attacks,
where a single process would consume huge amounts of kernel memory.
There is no a-prio limit in the kernel which would prevent you from
making the number as large as you want (well, within reason: map_count
is a signed 32-bit variable...).

	--david
Received on Mon Aug 05 13:32:41 2002

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:09 EST