Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[Benjamin Herrenschmidt]

On Tue, 2010-04-06 at 14:52 +0900, KOSAKI Motohiro wrote:

(Adding linux-arch)

> This check was introduced the following commit. yes now we don't
> consider arch specific PROT_xx flags. but I don't think it is odd.
> 
> Yeah, I can imagine at least embedded people certenary need arch
> specific PROT_xx flags and they hope to change it. but I don't 
> think mprotect() fit for your usage. I mean mprotect() is widely 
> used glibc internally. then, If mprotec can change which flags, 
> glibc might turn off such flags implictly.
> 
> So, Why can't we proper new syscall? It has no regression risk. 

I don't care much personally whether we use mprotect() or a new syscall,
but at this stage we already have PROT_SAO going that way for powerpc so
that would be an ABI change.

However, the main issue isn't really there. The main issue is that right
now, everything we do in mmap.c, mprotect.c, ... revolves around having
everything translated into the single vm_flags field. VMA merging
decisions, construction of vm_page_prot, etc... everything is there.

However, this is a 32-bit field on 32-bit archs, and we already use all
possible bits in there. It's also a field entirely defined in generic
code with no provision for arch specific bits.

The question here thus boils down to what direction do we want to go to
if we want to untangle that and provide the ability to expose mapping
"attributes" basically. In fact, I suspect even x86 might have good use
of that to create things like relaxed ordering mappings no ?

This boils down, so far to a few facts/questions to be resolved:

 - Do we want to use the existing PROT_ argument to mmap, mprotect,... ?
There's plenty of bit space, and we already have at least one example of
an arch adding something to it (powerpc with PROT_SAO - aka Strong
Access Ordering - aka Make It Look Like An x86 :-)

 - If not, while a separate syscall would be fine with me for setting
attributes after the fact, it makes it harder to pass them via mmap, is
that a big deal ? IE. Ie it means one -always- has to call it after mmap
to change the attributes. That means for example that mmap will
potentially create a VMA merged with another one, just to be re-split
due to the attribute change. A bit gross...

 - Do we want to keep the current "Funnel everything into vm_flags"
approach ? That leaves no option that I can see but to extend it into a
u64 so it grows on 32-bit archs. 

 - If not, I see two approaches here: Either having a separate / new
"attribute" field in the VMA or going straight for the vm_page_prot (ie.
the pgprot). In both cases, things like vma_merge() need to grow a new
argument since obviously we can't merge things with different
attributes.

 - ... Unless we just replace VM_SAO with VM_CANT_MERGE and set that
whenever a VMA has a non-0 attributes. Sad but simpler

Any other / better idea ?

Cheers,
Ben.


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

Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[Benjamin Herrenschmidt]

On Tue, 2010-04-06 at 14:52 +0900, KOSAKI Motohiro wrote:

(Adding linux-arch)

> This check was introduced the following commit. yes now we don't
> consider arch specific PROT_xx flags. but I don't think it is odd.
> 
> Yeah, I can imagine at least embedded people certenary need arch
> specific PROT_xx flags and they hope to change it. but I don't 
> think mprotect() fit for your usage. I mean mprotect() is widely 
> used glibc internally. then, If mprotec can change which flags, 
> glibc might turn off such flags implictly.
> 
> So, Why can't we proper new syscall? It has no regression risk. 

I don't care much personally whether we use mprotect() or a new syscall,
but at this stage we already have PROT_SAO going that way for powerpc so
that would be an ABI change.

However, the main issue isn't really there. The main issue is that right
now, everything we do in mmap.c, mprotect.c, ... revolves around having
everything translated into the single vm_flags field. VMA merging
decisions, construction of vm_page_prot, etc... everything is there.

However, this is a 32-bit field on 32-bit archs, and we already use all
possible bits in there. It's also a field entirely defined in generic
code with no provision for arch specific bits.

The question here thus boils down to what direction do we want to go to
if we want to untangle that and provide the ability to expose mapping
"attributes" basically. In fact, I suspect even x86 might have good use
of that to create things like relaxed ordering mappings no ?

This boils down, so far to a few facts/questions to be resolved:

 - Do we want to use the existing PROT_ argument to mmap, mprotect,... ?
There's plenty of bit space, and we already have at least one example of
an arch adding something to it (powerpc with PROT_SAO - aka Strong
Access Ordering - aka Make It Look Like An x86 :-)

 - If not, while a separate syscall would be fine with me for setting
attributes after the fact, it makes it harder to pass them via mmap, is
that a big deal ? IE. Ie it means one -always- has to call it after mmap
to change the attributes. That means for example that mmap will
potentially create a VMA merged with another one, just to be re-split
due to the attribute change. A bit gross...

 - Do we want to keep the current "Funnel everything into vm_flags"
approach ? That leaves no option that I can see but to extend it into a
u64 so it grows on 32-bit archs. 

 - If not, I see two approaches here: Either having a separate / new
"attribute" field in the VMA or going straight for the vm_page_prot (ie.
the pgprot). In both cases, things like vma_merge() need to grow a new
argument since obviously we can't merge things with different
attributes.

 - ... Unless we just replace VM_SAO with VM_CANT_MERGE and set that
whenever a VMA has a non-0 attributes. Sad but simpler

Any other / better idea ?

Cheers,
Ben.

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[KOSAKI Motohiro]

> On Tue, 2010-04-06 at 14:52 +0900, KOSAKI Motohiro wrote:
> 
> (Adding linux-arch)
> 
> > This check was introduced the following commit. yes now we don't
> > consider arch specific PROT_xx flags. but I don't think it is odd.
> > 
> > Yeah, I can imagine at least embedded people certenary need arch
> > specific PROT_xx flags and they hope to change it. but I don't 
> > think mprotect() fit for your usage. I mean mprotect() is widely 
> > used glibc internally. then, If mprotec can change which flags, 
> > glibc might turn off such flags implictly.
> > 
> > So, Why can't we proper new syscall? It has no regression risk. 
> 
> I don't care much personally whether we use mprotect() or a new syscall,
> but at this stage we already have PROT_SAO going that way for powerpc so
> that would be an ABI change.
> 
> However, the main issue isn't really there. The main issue is that right
> now, everything we do in mmap.c, mprotect.c, ... revolves around having
> everything translated into the single vm_flags field. VMA merging
> decisions, construction of vm_page_prot, etc... everything is there.
> 
> However, this is a 32-bit field on 32-bit archs, and we already use all
> possible bits in there. It's also a field entirely defined in generic
> code with no provision for arch specific bits.
> 
> The question here thus boils down to what direction do we want to go to
> if we want to untangle that and provide the ability to expose mapping
> "attributes" basically. In fact, I suspect even x86 might have good use
> of that to create things like relaxed ordering mappings no ?
> 
> This boils down, so far to a few facts/questions to be resolved:
> 
>  - Do we want to use the existing PROT_ argument to mmap, mprotect,... ?
> There's plenty of bit space, and we already have at least one example of
> an arch adding something to it (powerpc with PROT_SAO - aka Strong
> Access Ordering - aka Make It Look Like An x86 :-)
> 
>  - If not, while a separate syscall would be fine with me for setting
> attributes after the fact, it makes it harder to pass them via mmap, is
> that a big deal ? IE. Ie it means one -always- has to call it after mmap
> to change the attributes. That means for example that mmap will
> potentially create a VMA merged with another one, just to be re-split
> due to the attribute change. A bit gross...
> 
>  - Do we want to keep the current "Funnel everything into vm_flags"
> approach ? That leaves no option that I can see but to extend it into a
> u64 so it grows on 32-bit archs. 
> 
>  - If not, I see two approaches here: Either having a separate / new
> "attribute" field in the VMA or going straight for the vm_page_prot (ie.
> the pgprot). In both cases, things like vma_merge() need to grow a new
> argument since obviously we can't merge things with different
> attributes.
> 
>  - ... Unless we just replace VM_SAO with VM_CANT_MERGE and set that
> whenever a VMA has a non-0 attributes. Sad but simpler
> 
> Any other / better idea ?

I guess you haven't catch my intention. I didn't say we have to remove 
PROT_SAO and VM_SAO.
I mean mmap(PROT_SAO) is ok, it's only append new flag, not change exiting
flags meanings. I'm only against mprotect(PROT_NONE) turn off PROT_SAO
implicitely.

IOW I recommend we use three syscall
	mmap()		create new mappings
	mprotect()	change a protection of mapping (as a name)
	mattribute(): (or similar name)
			change an attribute of mapping (e.g. PROT_SAO or
			another arch specific flags)

I'm not against changing mm/protect.c for PROT_SAO.



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

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[KOSAKI Motohiro]

> On Tue, 2010-04-06 at 14:52 +0900, KOSAKI Motohiro wrote:
> 
> (Adding linux-arch)
> 
> > This check was introduced the following commit. yes now we don't
> > consider arch specific PROT_xx flags. but I don't think it is odd.
> > 
> > Yeah, I can imagine at least embedded people certenary need arch
> > specific PROT_xx flags and they hope to change it. but I don't 
> > think mprotect() fit for your usage. I mean mprotect() is widely 
> > used glibc internally. then, If mprotec can change which flags, 
> > glibc might turn off such flags implictly.
> > 
> > So, Why can't we proper new syscall? It has no regression risk. 
> 
> I don't care much personally whether we use mprotect() or a new syscall,
> but at this stage we already have PROT_SAO going that way for powerpc so
> that would be an ABI change.
> 
> However, the main issue isn't really there. The main issue is that right
> now, everything we do in mmap.c, mprotect.c, ... revolves around having
> everything translated into the single vm_flags field. VMA merging
> decisions, construction of vm_page_prot, etc... everything is there.
> 
> However, this is a 32-bit field on 32-bit archs, and we already use all
> possible bits in there. It's also a field entirely defined in generic
> code with no provision for arch specific bits.
> 
> The question here thus boils down to what direction do we want to go to
> if we want to untangle that and provide the ability to expose mapping
> "attributes" basically. In fact, I suspect even x86 might have good use
> of that to create things like relaxed ordering mappings no ?
> 
> This boils down, so far to a few facts/questions to be resolved:
> 
>  - Do we want to use the existing PROT_ argument to mmap, mprotect,... ?
> There's plenty of bit space, and we already have at least one example of
> an arch adding something to it (powerpc with PROT_SAO - aka Strong
> Access Ordering - aka Make It Look Like An x86 :-)
> 
>  - If not, while a separate syscall would be fine with me for setting
> attributes after the fact, it makes it harder to pass them via mmap, is
> that a big deal ? IE. Ie it means one -always- has to call it after mmap
> to change the attributes. That means for example that mmap will
> potentially create a VMA merged with another one, just to be re-split
> due to the attribute change. A bit gross...
> 
>  - Do we want to keep the current "Funnel everything into vm_flags"
> approach ? That leaves no option that I can see but to extend it into a
> u64 so it grows on 32-bit archs. 
> 
>  - If not, I see two approaches here: Either having a separate / new
> "attribute" field in the VMA or going straight for the vm_page_prot (ie.
> the pgprot). In both cases, things like vma_merge() need to grow a new
> argument since obviously we can't merge things with different
> attributes.
> 
>  - ... Unless we just replace VM_SAO with VM_CANT_MERGE and set that
> whenever a VMA has a non-0 attributes. Sad but simpler
> 
> Any other / better idea ?

I guess you haven't catch my intention. I didn't say we have to remove 
PROT_SAO and VM_SAO.
I mean mmap(PROT_SAO) is ok, it's only append new flag, not change exiting
flags meanings. I'm only against mprotect(PROT_NONE) turn off PROT_SAO
implicitely.

IOW I recommend we use three syscall
	mmap()		create new mappings
	mprotect()	change a protection of mapping (as a name)
	mattribute(): (or similar name)
			change an attribute of mapping (e.g. PROT_SAO or
			another arch specific flags)

I'm not against changing mm/protect.c for PROT_SAO.

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[Benjamin Herrenschmidt]

On Tue, 2010-04-06 at 15:24 +0900, KOSAKI Motohiro wrote:

> I guess you haven't catch my intention. I didn't say we have to remove 
> PROT_SAO and VM_SAO.
> I mean mmap(PROT_SAO) is ok, it's only append new flag, not change exiting
> flags meanings. I'm only against mprotect(PROT_NONE) turn off PROT_SAO
> implicitely.
> 
> IOW I recommend we use three syscall
> 	mmap()		create new mappings
> 	mprotect()	change a protection of mapping (as a name)
> 	mattribute(): (or similar name)
> 			change an attribute of mapping (e.g. PROT_SAO or
> 			another arch specific flags)
> 
> I'm not against changing mm/protect.c for PROT_SAO.

Ok, I see. No biggie. The main deal remains how we want to do that
inside the kernel :-) I think the less horrible options here are
to either extend vm_flags to always be 64-bit, or add a separate
vm_map_attributes flag, and add the necessary bits and pieces to
prevent merge accross different attribute vma's.

The more I try to hack it into vm_page_prot, the more I hate that
option.

Cheers
Ben.

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[KOSAKI Motohiro]

> Ok, I see. No biggie. The main deal remains how we want to do that
> inside the kernel :-) I think the less horrible options here are
> to either extend vm_flags to always be 64-bit, or add a separate
> vm_map_attributes flag, and add the necessary bits and pieces to
> prevent merge accross different attribute vma's.

vma->vm_flags already have VM_SAO. Why do we need more flags?
At least, I dislike to add separate flags member into vma.
It might introduce unnecessary messy into vma merge thing.



> The more I try to hack it into vm_page_prot, the more I hate that
> option.

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[Benjamin Herrenschmidt]

On Tue, 2010-04-06 at 19:26 +0900, KOSAKI Motohiro wrote:
> > Ok, I see. No biggie. The main deal remains how we want to do that
> > inside the kernel :-) I think the less horrible options here are
> > to either extend vm_flags to always be 64-bit, or add a separate
> > vm_map_attributes flag, and add the necessary bits and pieces to
> > prevent merge accross different attribute vma's.
> 
> vma->vm_flags already have VM_SAO. Why do we need more flags?
> At least, I dislike to add separate flags member into vma.
> It might introduce unnecessary messy into vma merge thing.

Well, we did shove SAO in there, and used up the very last vm_flag for
it a while back. Now I need another one, for little endian mappings. So
I'm stuck.

But the problem goes further I believe. Archs do nowadays have quite an
interesting set of MMU attributes that it would be useful to expose to
some extent.

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 :-)

Cheers,
Ben.

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[KOSAKI Motohiro]

> On Tue, 2010-04-06 at 19:26 +0900, KOSAKI Motohiro wrote:
> > > Ok, I see. No biggie. The main deal remains how we want to do that
> > > inside the kernel :-) I think the less horrible options here are
> > > to either extend vm_flags to always be 64-bit, or add a separate
> > > vm_map_attributes flag, and add the necessary bits and pieces to
> > > prevent merge accross different attribute vma's.
> > 
> > vma->vm_flags already have VM_SAO. Why do we need more flags?
> > At least, I dislike to add separate flags member into vma.
> > It might introduce unnecessary messy into vma merge thing.
> 
> Well, we did shove SAO in there, and used up the very last vm_flag for
> it a while back. Now I need another one, for little endian mappings. So
> I'm stuck.
> 
> But the problem goes further I believe. Archs do nowadays have quite an
> interesting set of MMU attributes that it would be useful to expose to
> some extent.

Generally speaking, It seems no good idea. desktop and server world don't
interest arch specific mmu attribute crap. 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. 

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


> 
> 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 :-)

Re: Arch specific mmap attributes

[David Miller]

From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date: Wed,  7 Apr 2010 15:03:45 +0900 (JST)

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

Desktop already uses similar features via PCI mmap
attributes and such, not to mention MSR settings on
x86.

So I disagree with your assesment that this is some
HPC/embedded issue.

Re: Arch specific mmap attributes

[KOSAKI Motohiro]

> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Date: Wed,  7 Apr 2010 15:03:45 +0900 (JST)
> 
> > I'm not against changing kernel internal. I only disagree mmu
> > attribute fashion will be become used widely.
> 
> Desktop already uses similar features via PCI mmap
> attributes and such, not to mention MSR settings on
> x86.

Probably I haven't catch your mention. Why userland process
need to change PCI mmap attribute by mmap(2)? It seems kernel issue.



> So I disagree with your assesment that this is some
> HPC/embedded issue.

Re: Arch specific mmap attributes

[David Miller]

From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date: Wed,  7 Apr 2010 16:14:29 +0900 (JST)

>> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Date: Wed,  7 Apr 2010 15:03:45 +0900 (JST)
>> 
>> > I'm not against changing kernel internal. I only disagree mmu
>> > attribute fashion will be become used widely.
>> 
>> Desktop already uses similar features via PCI mmap
>> attributes and such, not to mention MSR settings on
>> x86.
> 
> Probably I haven't catch your mention. Why userland process
> need to change PCI mmap attribute by mmap(2)? It seems kernel issue.

It uses PCI specific fd ioctls to change the attributes.

It's the same thing as extending the mmap() attribute space, but in a
device specific way.

I think evice and platform specific mmap() attributes are basically
inevitable, at any level, embedded or desktop or whatever.  The
fact that we've hacked around the issue with device specific
interfaces like the PCI device ioctls, is no excuse to not
tackle the issue directly and come up with something usable.

Re: Arch specific mmap attributes

[Benjamin Herrenschmidt]

On Wed, 2010-04-07 at 16:14 +0900, KOSAKI Motohiro wrote:
> > Desktop already uses similar features via PCI mmap
> > attributes and such, not to mention MSR settings on
> > x86.
> 
> Probably I haven't catch your mention. Why userland process
> need to change PCI mmap attribute by mmap(2)? It seems kernel issue.

There are cases where the userspace based driver needs to control
attributes such as write combining, or even cachability when mapping PCI
devices directly into userspace.

It's not -that- common, though X still does it on a number of platforms,
and there are people still trying to run PCI drivers in userspace ;-) 

But regardless. I don't see why HPC or Embedded would have to be
qualified as "crap" and not warrant our full attention into devising
something sane and clean anyways.

Cheers,
Ben.

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

Re: Arch specific mmap attributes

[Benjamin Herrenschmidt]

On Wed, 2010-04-07 at 16:14 +0900, KOSAKI Motohiro wrote:
> > Desktop already uses similar features via PCI mmap
> > attributes and such, not to mention MSR settings on
> > x86.
> 
> Probably I haven't catch your mention. Why userland process
> need to change PCI mmap attribute by mmap(2)? It seems kernel issue.

There are cases where the userspace based driver needs to control
attributes such as write combining, or even cachability when mapping PCI
devices directly into userspace.

It's not -that- common, though X still does it on a number of platforms,
and there are people still trying to run PCI drivers in userspace ;-) 

But regardless. I don't see why HPC or Embedded would have to be
qualified as "crap" and not warrant our full attention into devising
something sane and clean anyways.

Cheers,
Ben.

Re: Arch specific mmap attributes

[Benjamin Herrenschmidt]

On Wed, 2010-04-07 at 00:03 -0700, David Miller wrote:
> > I'm not against changing kernel internal. I only disagree mmu
> > attribute fashion will be become used widely.
> 
> Desktop already uses similar features via PCI mmap
> attributes and such, not to mention MSR settings on
> x86.

This is a very good point, we've had all sort of trouble hacking that in
for PCI mmap, between trying to get write combine in, which we got
on /proc via a tweak I think we never got over to sysfs, and the ability
to control cachability, for which we used to have O_SYNC hacks
in /dev/mem, I think there is room for some nice and clean set of
attributes here.

Cheers,
Ben.


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

Re: Arch specific mmap attributes

[Benjamin Herrenschmidt]

On Wed, 2010-04-07 at 00:03 -0700, David Miller wrote:
> > I'm not against changing kernel internal. I only disagree mmu
> > attribute fashion will be become used widely.
> 
> Desktop already uses similar features via PCI mmap
> attributes and such, not to mention MSR settings on
> x86.

This is a very good point, we've had all sort of trouble hacking that in
for PCI mmap, between trying to get write combine in, which we got
on /proc via a tweak I think we never got over to sysfs, and the ability
to control cachability, for which we used to have O_SYNC hacks
in /dev/mem, I think there is room for some nice and clean set of
attributes here.

Cheers,
Ben.

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[Benjamin Herrenschmidt]

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>

Re: Arch specific mmap attributes (Was: mprotect pgprot handling weirdness)

[Benjamin Herrenschmidt]

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>