public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] mmap and malloc questions on IA-64 linux
Date: Mon, 05 Aug 2002 20:31:00 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905909@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905877@msgid-missing>

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


  parent reply	other threads:[~2002-08-05 20:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-01 16:47 [Linux-ia64] mmap and malloc questions on IA-64 linux Olivier, JeffreyX
2002-08-01 18:09 ` David Mosberger
2002-08-02 15:25 ` Olivier, JeffreyX
2002-08-02 21:08 ` David Mosberger
2002-08-05 15:40 ` Olivier, JeffreyX
2002-08-05 20:31 ` David Mosberger [this message]
2002-08-05 21:01 ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ia64-105590701905909@msgid-missing \
    --to=davidm@napali.hpl.hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox