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

Benjamin Herrenschmidt wrote:
>>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
> everybody...
> 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...

Well if we use a set of valid ranges, then we can start with generic code
that will set up ranges allowed by the syscall semantics.

Then the arch code could be called with that set of ranges, and perform
its modifications to that set.

Then driver/fs code could be called and perform its modifications.

Note that each call would only ever exclude ranges of virtual addresses,
increase alignment, and decrease permissions (or fail). So nobody steps
on anybody's toes. When the final set of ranges come out the other end,
you can run a generic allocator on them.

A range could be something like

struct {
	unsigned long start, end;
	pgprot prot;
	unsigned int align_bits;
	unsigned int other_flags;	

The problem I see with this is that it could be computationally too
expensive to have each layer process and validate/modify them. And
simply might just be overengineered for the job.

> 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.

This would add some constraint onto the ordering of whether driver or
arch gets called first, but still wouldn't invalidate the above...

> 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.

Yeah definitely a nice start. And of course things should be done
incrementally rather than thinking about a complete rewrite first ;)

SUSE Labs, Novell Inc.
Send instant messages to your online friends 

  reply	other threads:[~2007-03-22 10:29 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
2007-03-22 10:29     ` Nick Piggin [this message]
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 \ \ \ \ \ \
    --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).