public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schmidt <bernds_cb1@t-online.de>
To: David Howells <dhowells@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Wu, Bryan" <Bryan.Wu@analog.com>
Subject: Re: [PATCH] NOMMU: Separate out VMAs
Date: Mon, 20 Aug 2007 18:02:09 +0200	[thread overview]
Message-ID: <46C9BB01.7050008@t-online.de> (raw)
In-Reply-To: <16451.1187622768@redhat.com>

David Howells wrote:
> Bernd Schmidt <bernds_cb1@t-online.de> wrote:
> 
>> In do_mmap_private, I've commented out the logic to free excess pages, as it
>> fragments terribly
> 
> I wonder if there's a good heuristic for this.  The problem is that whilst
> not releasing excess pages _may_ seem like a good idea, if your system is
> something like a single persistent app, then it really is not.
> 
> For instance, if such an app allocates a byte over 16MB (perhaps implicitly in
> the binfmt driver), then you'd completely waste a large chunk of RAM.  In the
> 16MB+1 case, the wastage would be a byte less than 16MB.

I think it would be good to have a mechanism to group free pages by 
purpose - so that if we break up a high-order page in order to allocate 
memory for process A, then the remaining pages remain in a special pool 
that the allocator will prefer to hand out only to process A.


>> Also, I think you're freeing high-order pages unaligned to
>> their order?
> 
> Yeah, but some of the pages might still be in use when we want to release
> them.

Not following you here.  Is it valid to free an order-2 page that's not 
aligned at order-2?

>> In do_munmap, we can deal with freeing more than one vma.  I've not touched
>> the rb-tree logic in the shared file case, as I have no idea what it's trying
>> to do given that only exact matches are allowed.
> 
> I'd generally rather not do this.  You can't use MAP_FIXED to request adjacent
> regions, so why should you anticipate there would be any?

Adjacent regions can happen by accident, and the uClibc malloc will try 
to merge free areas when they are adjacent - there's a lot of 
special-case code in there to prevent this on uClinux systems by 
essentially duplicating VMA tracking.  That's something we want to 
avoid, because it eats performance (especially in threaded apps due to 
additional locking).


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

      reply	other threads:[~2007-08-20 16:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-08 13:53 [PATCH, RFD]: Unbreak no-mmu mmap Bernd Schmidt
2007-06-09 19:10 ` Matt Mackall
2007-06-11 21:08   ` Robin Getz
2007-06-11 22:09   ` Mike Frysinger
2007-06-11 23:04     ` Bernd Schmidt
2007-06-11 23:22       ` Mike Frysinger
2007-06-19 23:26 ` Robin Getz
2007-06-20  2:38   ` Bryan Wu
2007-06-20  3:00 ` Paul Mundt
2007-06-20  3:18   ` Bryan Wu
2007-06-27  5:50     ` Greg Ungerer
2007-06-22 12:59 ` David Howells
2007-06-22 13:35 ` David Howells
2007-06-22 14:29 ` [PATCH] NOMMU: " David Howells
2007-08-01 12:29 ` [PATCH, RFD]: " David Howells
2007-08-03 14:03 ` [PATCH] NOMMU: Separate out VMAs David Howells
2007-08-07 13:12   ` Bernd Schmidt
2007-08-07 13:17     ` David Howells
2007-08-07 13:21       ` David Howells
2007-08-07 13:37         ` Bernd Schmidt
2007-08-07 14:03           ` David Howells
2007-08-17 11:49         ` Bernd Schmidt
2007-08-20 15:12           ` David Howells
2007-08-20 16:02             ` Bernd Schmidt [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=46C9BB01.7050008@t-online.de \
    --to=bernds_cb1@t-online.de \
    --cc=Bryan.Wu@analog.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@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