linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-mm@kvack.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Nick Piggin <npiggin@suse.de>,
	Hugh Dickins <hugh.dickins@tiscali.co.uk>
Subject: Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)
Date: Wed, 07 Apr 2010 18:56:13 +1000	[thread overview]
Message-ID: <1270630573.2300.90.camel@pasglop> (raw)
In-Reply-To: <20100407095145.FB70.A69D9226@jp.fujitsu.com>

On Wed, 2010-04-07 at 15:03 +0900, KOSAKI Motohiro wrote:

> Generally speaking, It seems no good idea. desktop and server world don't
> interest arch specific mmu attribute crap.

So you are saying that because your desktop and servers don't care Linux
shouldn't support the possiblity ? IE. Embedded doesn't matter or some
sort of similar statement ? :-) Come on ...

Anyways, this is just not true. Take SAO, this is a server feature (used
among others for x86 emulation). Little Endian mappings is indeed more
of an "embedded" feature to some extent, at least the way we plan to use
it, but is still very relevant.

Caching attributes control and storage keys can be useful in a lot of
other areas that really have nothing to do with HPC :-) Databases come
to mind, there's more too.

In any case, I don't know why you argue. We have features that a lot of
the CPUs out there provide, that at least some people out there would
like to exploit, and you are saying that Linux should not provide
support for these because your vision of a desktop/server only world is
all that matters ?

Anyways, let's go back to -how- to implement that properly rather than
that sort of reasonably useless argument.

> because many many opensource
> and ISV library don't care it. I know highend hpc and embedded have 
> differenct eco-system. they might want to use such strange mmu feature.
> I recommend to you are focusing popwerpc eco-system. 

Thanks you for your recommendation :-)

> I'm not against changing kernel internal. I only disagree mmu attribute
> fashion will be become used widely.

So how do you propose we proceed ? Extend vm_flags to be a u64 instead ?

I don't really care much which method is used, though from a -technical-
perspective, the mmu attributes one seem to be nicer in the long run,
but my immediate needs would be well served by just adding 2 or 3 flags
in there :-)

In any case, I'd be curious to have Hugh and Nick opinions here on the
technicalities.

Cheers,
Ben.

> > Some powerpc's also provide storage keys for example and I think ARM
> > have something along those lines. There's interesting cachability
> > attributes too, on x86 as well. Being able to use such attributes to
> > request for example a relaxed ordering mapping on x86 might be useful.
> > 
> > I think it basically boils down to either extend vm_flags to always be
> > 64-bit, which seems to be Nick preferred approach, or introduct a
> > vm_attributes with all the necessary changes to the merge code to take
> > it into account (not -that- hard tho, there's only half a page of
> > results in grep for these things :-)
> 
> 
> 
> 
> --
> 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:"dont@kvack.org"> email@kvack.org </a>


--
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:"dont@kvack.org"> email@kvack.org </a>

      parent reply	other threads:[~2010-04-07  8:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-06  5:09 mprotect pgprot handling weirdness Benjamin Herrenschmidt
2010-04-06  5:32 ` Benjamin Herrenschmidt
2010-04-06  5:43 ` Benjamin Herrenschmidt
2010-04-06  5:52 ` KOSAKI Motohiro
2010-04-06  6:07   ` Arch specific mmap attributes (Was: mprotect pgprot handling weirdness) Benjamin Herrenschmidt
2010-04-06  6:24     ` KOSAKI Motohiro
2010-04-06  7:30       ` Benjamin Herrenschmidt
2010-04-06 10:26         ` KOSAKI Motohiro
2010-04-06 22:15           ` Benjamin Herrenschmidt
2010-04-07  6:03             ` KOSAKI Motohiro
2010-04-07  7:03               ` Arch specific mmap attributes David Miller
2010-04-07  7:14                 ` KOSAKI Motohiro
2010-04-07  7:18                   ` David Miller
2010-04-07  9:00                   ` Benjamin Herrenschmidt
2010-04-07  8:58                 ` Benjamin Herrenschmidt
2010-04-07  8:56               ` 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:
  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=1270630573.2300.90.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).