From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: grg22@ai.mit.edu
Cc: Linux-MM@kvack.org, torvalds@transmeta.com
Subject: Re: mmap doesn't "wrap?"
Date: Sat, 7 Aug 1999 00:45:37 -0700 (PDT) [thread overview]
Message-ID: <199908070745.AAA97113@google.engr.sgi.com> (raw)
In-Reply-To: <199908070311.XAA03580@skydive.ai.mit.edu> from "grg22@ai.mit.edu" at Aug 6, 99 11:11:58 pm
>
> It looks to me as though mmap will try to grab a region of memory whose
> address is greater than or equal to the suggested start address passed in
> the call. I suppose it does this because it traverses the free list in
> ascending address order. If it can't find enough memory above the
> requested address, then the mmap fails, claiming ENOMEM; and it does this
> even when you've got gigs of wide open address space below the suggested
> address.
>
> One effect of this is that if you specify an address of 0 (saying "I don't
> care"), the mmap seems to start above 0x40000000 by default, and forever
> ignores the gigabyte of address space below that. This seems undesirable,
> especially when your chunk of memory requested would fit below 0x4000000
> but can't fit above it (due to memory fragmentation, or because you've
> already used up the rest of it!).
>
> I don't know if the right thing would be to change the behavior of
> get_unmapped_area() to "wrap" from the beginning of the free list when it
> can't find anything above the given address, or just add a failure clause
> into do_mmap() to try again starting from 0 (or something else?).
>
>
> (Yes, I've patched my rlimits so I can access 3GB virtual and yes, I
> commit the sin of addressing the 32-bit community only on this more
> general mailing list: apologies to you lucky 64-bit folks.)
>
> thx,
> grg
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://humbolt.geo.uu.nl/Linux-MM/
>
Look at my patch for get_unmapped_area() at
http://reality.sgi.com/kanoj_engr/garea.html
This has been submitted to Linus previously, unfortunately, it has not
been accepted. The current get_unmapped_area() is not POSIX compliant
according to my thinking.
Regarding TASK_UNMAPPED_BASE, you can browse
http://reality.sgi.com/kanoj_engr/tuning.html
which has some pointers on how to use the 3Gb user space judiciously.
Basically, you can tune TASK_UNMAPPED_BASE to 0x10000000, if your apps
are "well-behaved".
Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
prev parent reply other threads:[~1999-08-07 7:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-07 3:11 grg22
1999-08-07 7:45 ` Kanoj Sarcar [this message]
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=199908070745.AAA97113@google.engr.sgi.com \
--to=kanoj@google.engr.sgi.com \
--cc=Linux-MM@kvack.org \
--cc=grg22@ai.mit.edu \
--cc=torvalds@transmeta.com \
/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