LKML Archive on
help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <>
To: Nick Piggin <>
Cc: Linux Memory Management <>,
Subject: Re: [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area
Date: Thu, 22 Mar 2007 21:14:58 +1100	[thread overview]
Message-ID: <1174558498.10836.30.camel@localhost.localdomain> (raw)
In-Reply-To: <>

> Great, this is long overdue for a cleanup.

Indeed... lots of redundant checks, dead code, etc...

> I haven't looked at all users of this, but does it make sense to switch
> to an API that takes an address range and modifies / filters it? Perhaps
> also filling in some other annotations (eg. alignment, topdown/bottom up).
> This way you could stack as many arch and driver callbacks as you need,
> while hopefully also having just a single generic allocator.
> OTOH, that might end up being too inefficient or simply over engineered.
> Did you have any other thoughts about how to do this more generically?

I haven't quite managed to think about something that would fit

The main problem is that the requirements are fairly arch specific in
nature... from page sizes, page attributes, to things like nommu who
want in some case to enfore virt=phys or to cache aliasing issues.

I think we can find a subset of "parameters" that represent the various
constraints... pgprot, page size, mostly. Then, we could stack up the
driver/fs g_u_a on top of the arch one, but it's not simple to do that
right. Who get's to pick an address first ? If the driver picks one but
the arch rejects it, the driver need a chance to pick another one ...

Or do we decide that only the arch knows, and thus the driver only
provides more detailed informations to the arch to pick something up...

That would be useful.. for example, some archs could really use knowing
at g_u_a time wether the mapping is to be cacheable or non cacheable.

I'm still thinking about it. I think my first patch set is a good step
to give some more flexibility to archs but is by no mean something to
settle on.

I need to simmer that more until my neurons manage to cough up some
nicer & generic abstraction/api to deal with that in a better way.


  reply	other threads:[~2007-03-22 10:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-22  6:00 Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 1/15] get_unmapped_area handles MAP_FIXED on powerpc Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 2/15] get_unmapped_area handles MAP_FIXED on alpha Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 3/15] get_unmapped_area handles MAP_FIXED on arm Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 4/15] get_unmapped_area handles MAP_FIXED on frv Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 5/15] get_unmapped_area handles MAP_FIXED on i386 Benjamin Herrenschmidt
2007-03-22  6:00 ` [RFC/PATCH 6/15] get_unmapped_area handles MAP_FIXED on ia64 Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 7/15] get_unmapped_area handles MAP_FIXED on parisc Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 8/15] get_unmapped_area handles MAP_FIXED on sparc64 Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 9/15] get_unmapped_area handles MAP_FIXED on x86_64 Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 10/15] get_unmapped_area handles MAP_FIXED in hugetlbfs Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 11/15] get_unmapped_area handles MAP_FIXED on ramfs (nommu) Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 12/15] get_unmapped_area handles MAP_FIXED in ffb DRM Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 13/15] get_unmapped_area handles MAP_FIXED in /dev/mem (nommu) Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 15/15] get_unmapped_area doesn't need hugetlbfs hacks anymore Benjamin Herrenschmidt
2007-03-22  6:01 ` [RFC/PATCH 14/15] get_unmapped_area handles MAP_FIXED in generic code Benjamin Herrenschmidt
2007-03-22  7:29 ` [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area Nick Piggin
2007-03-22 10:14   ` Benjamin Herrenschmidt [this message]
2007-03-22 10:29     ` Nick Piggin
2007-03-22 10:38       ` Benjamin Herrenschmidt

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:

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

  git send-email \
    --in-reply-to=1174558498.10836.30.camel@localhost.localdomain \ \ \ \ \
    --subject='Re: [RFC/PATCH 0/15] Pass MAP_FIXED down to get_unmapped_area' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).