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