From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hughd@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Ben Herrenschmidt <benh@kernel.crashing.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Subject: Re: [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit
Date: Wed, 21 Mar 2012 17:16:06 +0400 [thread overview]
Message-ID: <4F69D496.2040509@openvz.org> (raw)
In-Reply-To: <20120321100602.GA5522@barrios>
Minchan Kim wrote:
> Hi Konstantin,
>
> It seems to be nice clean up to me and you are a volunteer we have been wanted
> for a long time. Thanks!
> I am one of people who really want to expand vm_flags to 64 bit but when KOSAKI
> tried it, Linus said his concerning, I guess you already saw that.
>
> He want to tidy vm_flags's usage up rather than expanding it.
> Without the discussion about that, just expanding vm_flags would make us use
> it up easily so that we might need more space.
Strictly speaking, my pachset does not expands vm_flags, it just prepares to this.
Anyway vm_flags_t looks better than hard-coded "unsigned long" and messy type-casts around it.
>
> Readahead flags are good candidate to move into another space and arch-specific flags, I guess.
> Another candidate I think of is THP flag. It's just for only anonymous vma now
> (But I am not sure we have a plan to support it for file-backed pages in future)
> so we can move it to anon_vma or somewhere.
> I think other guys might find more somethings
>
> The point is that at least, we have to discuss about clean up current vm_flags's
> use cases before expanding it unconditionally.
Seems like we can easily remove VM_EXECUTABLE
(count in mm->num_exe_file_vmas amount of vmas with vma->vm_file == mm->exe_file
instead of vmas with VM_EXECUTABLE bit)
And probably VM_CAN_NONLINEAR...
>
> On Wed, Mar 21, 2012 at 10:56:07AM +0400, Konstantin Khlebnikov wrote:
>> There is good old tradition: every year somebody submit patches for extending
>> vma->vm_flags upto 64-bits, because there no free bits left on 32-bit systems.
>>
>> previous attempts:
>> https://lkml.org/lkml/2011/4/12/24 (KOSAKI Motohiro)
>> https://lkml.org/lkml/2010/4/27/23 (Benjamin Herrenschmidt)
>> https://lkml.org/lkml/2009/10/1/202 (Hugh Dickins)
>>
>> Here already exist special type for this: vm_flags_t, but not all code uses it.
>> So, before switching vm_flags_t from unsinged long to u64 we must spread
>> vm_flags_t everywhere and fix all possible type-casting problems.
>>
>> There is no functional changes in this patch set,
>> it only prepares code for vma->vm_flags converting.
>>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hughd@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Ben Herrenschmidt <benh@kernel.crashing.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Subject: Re: [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit
Date: Wed, 21 Mar 2012 17:16:06 +0400 [thread overview]
Message-ID: <4F69D496.2040509@openvz.org> (raw)
In-Reply-To: <20120321100602.GA5522@barrios>
Minchan Kim wrote:
> Hi Konstantin,
>
> It seems to be nice clean up to me and you are a volunteer we have been wanted
> for a long time. Thanks!
> I am one of people who really want to expand vm_flags to 64 bit but when KOSAKI
> tried it, Linus said his concerning, I guess you already saw that.
>
> He want to tidy vm_flags's usage up rather than expanding it.
> Without the discussion about that, just expanding vm_flags would make us use
> it up easily so that we might need more space.
Strictly speaking, my pachset does not expands vm_flags, it just prepares to this.
Anyway vm_flags_t looks better than hard-coded "unsigned long" and messy type-casts around it.
>
> Readahead flags are good candidate to move into another space and arch-specific flags, I guess.
> Another candidate I think of is THP flag. It's just for only anonymous vma now
> (But I am not sure we have a plan to support it for file-backed pages in future)
> so we can move it to anon_vma or somewhere.
> I think other guys might find more somethings
>
> The point is that at least, we have to discuss about clean up current vm_flags's
> use cases before expanding it unconditionally.
Seems like we can easily remove VM_EXECUTABLE
(count in mm->num_exe_file_vmas amount of vmas with vma->vm_file == mm->exe_file
instead of vmas with VM_EXECUTABLE bit)
And probably VM_CAN_NONLINEAR...
>
> On Wed, Mar 21, 2012 at 10:56:07AM +0400, Konstantin Khlebnikov wrote:
>> There is good old tradition: every year somebody submit patches for extending
>> vma->vm_flags upto 64-bits, because there no free bits left on 32-bit systems.
>>
>> previous attempts:
>> https://lkml.org/lkml/2011/4/12/24 (KOSAKI Motohiro)
>> https://lkml.org/lkml/2010/4/27/23 (Benjamin Herrenschmidt)
>> https://lkml.org/lkml/2009/10/1/202 (Hugh Dickins)
>>
>> Here already exist special type for this: vm_flags_t, but not all code uses it.
>> So, before switching vm_flags_t from unsinged long to u64 we must spread
>> vm_flags_t everywhere and fix all possible type-casting problems.
>>
>> There is no functional changes in this patch set,
>> it only prepares code for vma->vm_flags converting.
>>
next prev parent reply other threads:[~2012-03-21 13:16 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 6:56 [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 01/16] mm: introduce NR_VMA_FLAGS Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 02/16] mm: use vm_flags_t for vma flags Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 03/16] mm/shmem: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 04/16] mm/nommu: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 7:08 ` Greg Ungerer
2012-03-21 7:08 ` Greg Ungerer
2012-03-21 7:20 ` Konstantin Khlebnikov
2012-03-21 7:20 ` Konstantin Khlebnikov
2012-03-21 12:01 ` [PATCH v2 " Konstantin Khlebnikov
2012-03-21 12:01 ` Konstantin Khlebnikov
2012-03-23 6:47 ` Greg Ungerer
2012-03-23 6:47 ` Greg Ungerer
2012-03-21 6:56 ` [PATCH 05/16] mm/drivers: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 10:34 ` Laurent Pinchart
2012-03-21 10:34 ` Laurent Pinchart
2012-03-21 14:46 ` Greg Kroah-Hartman
2012-03-21 14:46 ` Greg Kroah-Hartman
2012-03-21 6:56 ` [PATCH 06/16] mm/x86: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:57 ` H. Peter Anvin
2012-03-21 6:57 ` H. Peter Anvin
2012-03-21 6:56 ` [PATCH 07/16] mm/arm: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-22 21:21 ` Andrew Morton
2012-03-22 21:21 ` Andrew Morton
2012-03-22 21:21 ` Andrew Morton
2012-03-21 6:56 ` [PATCH 08/16] mm/unicore32: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-27 3:38 ` Guan Xuetao
2012-03-27 3:38 ` Guan Xuetao
2012-03-27 5:58 ` Konstantin Khlebnikov
2012-03-27 5:58 ` Konstantin Khlebnikov
2012-03-27 7:50 ` Guan Xuetao
2012-03-27 7:50 ` Guan Xuetao
2012-03-21 6:56 ` [PATCH 09/16] mm/ia64: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 10/16] mm/powerpc: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 11/16] mm/s390: " Konstantin Khlebnikov
2012-03-21 6:56 ` Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 12/16] mm/mips: " Konstantin Khlebnikov
2012-03-21 6:57 ` Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 13/16] mm/parisc: " Konstantin Khlebnikov
2012-03-21 6:57 ` Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 14/16] mm/score: " Konstantin Khlebnikov
2012-03-21 6:57 ` Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 15/16] mm: cast vm_flags_t to u64 before printing Konstantin Khlebnikov
2012-03-21 6:57 ` Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 16/16] mm: vm_flags_t strict type checking Konstantin Khlebnikov
2012-03-21 6:57 ` Konstantin Khlebnikov
2012-03-21 12:11 ` [PATCH v2 " Konstantin Khlebnikov
2012-03-21 12:11 ` Konstantin Khlebnikov
2012-03-21 10:06 ` [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit Minchan Kim
2012-03-21 10:06 ` Minchan Kim
2012-03-21 13:16 ` Konstantin Khlebnikov [this message]
2012-03-21 13:16 ` Konstantin Khlebnikov
2012-03-22 5:39 ` Minchan Kim
2012-03-22 5:39 ` Minchan Kim
2012-03-22 6:22 ` Benjamin Herrenschmidt
2012-03-22 6:22 ` Benjamin Herrenschmidt
2012-03-24 14:46 ` Konstantin Khlebnikov
2012-03-24 14:46 ` Konstantin Khlebnikov
2012-03-24 15:00 ` Konstantin Khlebnikov
2012-03-24 15:00 ` Konstantin Khlebnikov
2012-03-24 23:50 ` Benjamin Herrenschmidt
2012-03-24 23:50 ` Benjamin Herrenschmidt
2012-03-25 7:55 ` Konstantin Khlebnikov
2012-03-25 7:55 ` Konstantin Khlebnikov
2012-03-22 21:26 ` Andrew Morton
2012-03-22 21:26 ` Andrew Morton
2012-03-22 21:28 ` Al Viro
2012-03-22 21:28 ` Al Viro
2012-03-22 21:41 ` Andrew Morton
2012-03-22 21:41 ` Andrew Morton
2012-03-22 21:57 ` Al Viro
2012-03-22 21:57 ` Al Viro
2012-03-22 22:05 ` Konstantin Khlebnikov
2012-03-22 22:05 ` Konstantin Khlebnikov
2012-03-22 22:24 ` Konstantin Khlebnikov
2012-03-22 22:24 ` Konstantin Khlebnikov
2012-03-22 22:39 ` Linus Torvalds
2012-03-22 22:39 ` Linus Torvalds
2012-03-22 22:52 ` Konstantin Khlebnikov
2012-03-22 22:52 ` Konstantin Khlebnikov
2012-03-22 23:09 ` Andrew Morton
2012-03-22 23:09 ` Andrew Morton
2012-03-23 1:42 ` Al Viro
2012-03-23 1:42 ` Al Viro
2012-03-22 22:08 ` Linus Torvalds
2012-03-22 22:08 ` Linus Torvalds
2012-03-23 16:19 ` KOSAKI Motohiro
2012-03-23 16:19 ` KOSAKI Motohiro
2012-03-30 2:19 ` Al Viro
2012-03-30 2:19 ` Al Viro
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=4F69D496.2040509@openvz.org \
--to=khlebnikov@openvz.org \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=minchan@kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.