On Fri, 11 Nov 2011, Benjamin Herrenschmidt wrote:

On Thu, 2011-11-10 at 12:22 -0500, KOSAKI Motohiro wrote:

quoted

On 11/9/2011 11:09 PM, Nai Xia wrote:

quoted

Hi all,

Did this patch get merged at last, or on this way being merged, or
just dropped ?

Dropped.
Linus said he dislike 64bit enhancement.

Do you have a pointer ? (And a rationale)

I still want to put some arch flags in there at some point...

It was in this mail below, when Andrew sent Linus the patch, and Linus
opposed my "argument" in support: that wasn't on lkml or linux-mm,
but I don't see that its privacy needs protecting.

KOSAKI-san then sent instead a patch to correct some ints to longs,
which Linus did put in: but changing them to a new "vm_flags_t".

He was, I think, hoping that one of us would change all the other uses
of unsigned long vm_flags to vm_flags_t; but in fact none of us has
stepped up yet - yeah, we're still sulking that we didn't get our
shiny new 64-bit vm_flags ;)

I think Linus is not opposed to PowerPC and others defining a 64-bit
vm_flags_t if you need it, but wants not to bloat the x86_32 vma.

I'm still wary of the contortions we go to in constraining flags,
and feel that the 32-bit case holds back the 64-bit, which would
not itself be bloated at all.

The subject is likely to come up again, more pressingly, with page flags.

Hugh

From torvalds@linux-foundation.org Wed May 25 10:43:32 2011
Date: Wed, 25 May 2011 10:42:37 -0700
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, KOSAKI Motohiro <redacted>, Ben Herrenschmidt <benh@kernel.crashing.org>, dave@linux.vnet.ibm.com, KAMEZAWA Hiroyuki <redacted>
Subject: Re: [patch 023/141] mm: convert vma->vm_flags to 64 bit

On Wed, May 25, 2011 at 10:09 AM, Hugh Dickins [off-list ref] wrote:

quoted

If they don't absolutely want it today, they'll still be needing it
tomorrow...ish.

I think that's a very bogus argument.

I think having push-back for extending flags is a good idea. Some of
the vm_flags we have now are almost certainly just total crap, brought
on by people who said "let's just add a flag for this".

So if we don't have a situation where "we absolutely *have* to do
this, and we've tried everything else", then I don't think we should
encourage more of the same.

For example, do we care about VM_RESERVED vs VM_IO, for example? There
are some subtle (but quite frankly, probably pointless and entirely
historical) differences in how mlock() acts on them, for example.

Or what about the read-ahead flags? They don't seem sensible for
non-file-backed mappings, and if it's file-backed, we have "vm_file"
which actually has the whole read-ahead state in it. Do we really need
two bits for that? Does anybody really want to map the same "struct
file" (note: same particular "open()" call, not same file on disk)
multiple times and have different read-ahead for them?

IOW, I really don't see why more than 32 bits would be needed in the
first place, and I think people have been too eager to add bits to
begin with. And if we really *do* need more bits, I think we have some
options for that too, although I seriously think anybody who wants
more bits should ask themselves whether they are actually going to be
used, or are just some crazy feature that no sane person should care
about.

                       Linus

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>