From: Arjan van de Ven <arjanv@redhat.com>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: 'Wolfgang Wander' <wwc@rentec.com>,
'Andrew Morton' <akpm@osdl.org>,
mingo@elte.hu, linux-mm@kvack.org
Subject: Re: [PATCH] Avoiding mmap fragmentation - clean rev
Date: Wed, 18 May 2005 09:28:38 +0200 [thread overview]
Message-ID: <20050518072838.GB15326@devserv.devel.redhat.com> (raw)
In-Reply-To: <200505172228.j4HMSkg28528@unix-os.sc.intel.com>
On Tue, May 17, 2005 at 03:28:46PM -0700, Chen, Kenneth W wrote:
> This patch tries to solve address space fragmentation issue brought
> up by Wolfgang where fragmentation is so severe that application
> would fail on 2.6 kernel. Looking a bit deep into the issue, we
> found that a lot of fragmentation were caused by suboptimal algorithm
> in the munmap code path. For example, as people pointed out that
> when a series of munmap occurs, the free_area_cache would point to
> last vma that was freed, ignoring its surrounding and not performing
> any coalescing at all, thus artificially create more holes in the
> virtual address space than necessary. However, all the information
> needed to perform coalescing are actually already there. This patch
> put that data in use so we will prevent artificial fragmentation.
>
> This patch covers both bottom-up and top-down topology. For bottom-up
> topology, free_area_cache points to prev->vm_end. And for top-down,
> free_area_cache points to next->vm_start. The results are very promising,
> it passes the test case that Wolfgang posted and I have tested it on a
> variety of x86, x86_64, ia64 machines.
>
> Please note, this patch completely obsoletes previous patch that
> Wolfgang posted and should completely retain the performance benefit
> of free_area_cache and at the same time preserving fragmentation to
> minimum.
this has one downside (other than that I like it due to it's simplicity):
we've seen situations where there was a 4Kb gap at the start of the mmaps,
and then all future mmaps are bigger (say, stack sized). That 4Kb gap would
entirely void the advantage of the cache if the cache stuck to that 4kb gap.
(Personally I favor correctness above all but it does hurt performance
really bad)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-05-18 7:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E4BA51C8E4E9634993418831223F0A49291F06E1@scsmsx401.amr.corp.intel.com>
2005-05-17 22:28 ` Chen, Kenneth W
2005-05-18 7:28 ` Arjan van de Ven [this message]
2005-05-18 7:43 ` Ingo Molnar
2005-05-18 7:37 ` Ingo Molnar
2005-05-18 13:05 ` Wolfgang Wander
2005-05-18 15:47 ` Wolfgang Wander
2005-05-18 16:18 ` Chen, Kenneth W
2005-05-18 17:16 ` Wolfgang Wander
2005-05-18 17:57 ` Chen, Kenneth W
2005-05-19 18:38 ` Wolfgang Wander
2005-05-19 22:54 ` Andrew Morton
2005-05-20 2:02 ` Chen, Kenneth W
2005-05-20 23:51 ` Chen, Kenneth W
2005-05-23 18:25 ` Wolfgang Wander
2005-05-26 17:32 ` Wolfgang Wander
2005-05-26 17:44 ` Chen, Kenneth W
2005-05-20 3:10 ` Chen, Kenneth W
2005-05-20 12:39 ` Wolfgang Wander
2005-05-20 2:14 Chen, Kenneth W
2005-05-20 12:47 ` Wolfgang Wander
2005-05-25 7:30 linux
2005-05-27 16:37 Chen, Kenneth W
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=20050518072838.GB15326@devserv.devel.redhat.com \
--to=arjanv@redhat.com \
--cc=akpm@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=wwc@rentec.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