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:38:57 +1100	[thread overview]
Message-ID: <1174559937.10836.36.camel@localhost.localdomain> (raw)
In-Reply-To: <>

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

A bit complicated in practice... "set of ranges" can be big... depend on
what hthe restrictions actually are.

On powerpc, for example, the fs/driver don't even know. With my multiple
page size thingy for example, the only thing I want to rely on is the
page size of a given mapping. The arch code can open/close segments for
different page sizes depending if they have already some VMAs in them or
not. Thus providing ranges isn't a good idea.

With my slices patch (you can find it on linuxppc-dev, at least an older
version not base on that serie, I can post a newer one if you want), you
can see that hugetlbfs g_u_a basically turns into a single slice request
for a given page size and the arch code will automatically try to find a
segment already converted for that page size if any, if not, will try to
convert one that has no other VMAs in it.

Another counter example to you proposal is cacheable vs. cache
invalidate. A driver like /dev/mem or /proc/bus/pci only knows "cache
invalidate" in most case (and currently has no way to tell that to the
arch). It doesn't and shouldn't have to know what kind of rstrictions
the arch might have on such a mapping. Thus it shouldn't have to pick up
ranges. It doesn't care.
> This would add some constraint onto the ordering of whether driver or
> arch gets called first, but still wouldn't invalidate the above...

Problem is as I said above, driver doesn't really know about "ranges".
Driver really knows about constraints
> > 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 ;)



      reply	other threads:[~2007-03-22 10:39 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
2007-03-22 10:38       ` Benjamin Herrenschmidt [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:

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

  git send-email \
    --in-reply-to=1174559937.10836.36.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).