linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh.dickins@tiscali.co.uk>
To: Nigel Cunningham <ncunningham@crca.org.au>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Wu Fengguang <fengguang.wu@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: No more bits in vm_area_struct's vm_flags.
Date: Mon, 28 Sep 2009 22:21:27 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0909282200470.11529@sister.anvils> (raw)
In-Reply-To: <4AC03D9C.3020907@crca.org.au>

On Mon, 28 Sep 2009, Nigel Cunningham wrote:
> KAMEZAWA Hiroyuki wrote:
> > Then, Nigel, you have 2 choices I think.
> > 
> > (1) don't merge if vm_hints is set  or (2) pass vm_hints to all
> > __merge() functions.
> > 
> > One of above will be accesptable for stakeholders... I personally
> > like (1) but just trying (2) may be accepted.
> > 
> > What I dislike is making vm_flags to be long long ;)
> 
> Okay. I've gone for option 1 for now.

Arbitrary limitation, but not important at this stage.

> Here's what I currently have (compile testing as I write)...
> 
> 
> 
> vm_flags in struct vm_area_struct is full. Move some of the less commonly
> used flags to a new variable so that other flags that need to be in vm_flags
> (because, for example, they need to be in variables that are passed around)
> can be added.
> 
> Signed-off-by: Nigel Cunningham <nigel@tuxonice.net>

This is quite a small patch (much smaller than my unsigned long long
one, not that I've completed or posted that yet); but I'm afraid that
I do not like it.

First off, do you realize that unsigned long vm_hints adds a pointless
8 bytes to every vm_area_struct on 64-bit systems?  Pointless because
there was already space for the flags you've moved in 64-bit vm_flags.

You might eliminate the bloat by making it an unsigned int or unsigned
char and squeezing it into a gap between other fields; but it still
seems silly to separate them.

I agree that VM_SEQ_READ and VM_RAND_READ are low hanging fruit,
in that they stand out as odd, partly because of the CamelCase
macros which hide them from sight.  But many others of the flags
are their own peculiar cases too.

I don't think there's a great queue of people wanting to add more
read hints: nobody would be more likely to do so than Fengguang,
and even he worries about "vm_hints" limiting its scope.

If you're looking to make more flagspace available, then it would
need to accomodate motley other flags too, so should be called...
vm_flags2?  shudder!

Were it not for the bloat, I wouldn't hesitate over unsigned long long.

As it is, I think that (as I said before) we should first look to see
if we can cull just a few of the flags which have accumulated.  Then
move on to unsigned long long when we have to.

I suggested before that for the moment you reuse VM_MAPPED_COPY,
and you said "Okee doke".  What changed?

Hugh

  parent reply	other threads:[~2009-09-28 21:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-23  4:15 No more bits in vm_area_struct's vm_flags Nigel Cunningham
2009-09-23 20:23 ` Hugh Dickins
2009-09-25  8:30   ` Nigel Cunningham
2009-09-25 11:36     ` Hugh Dickins
2009-09-25 11:47       ` Nigel Cunningham
2009-09-30 12:02     ` Pavel Machek
2009-09-30 13:08       ` swsusp on nommu, was 'Re: No more bits in vm_area_struct's vm_flags.' Johannes Weiner
2009-09-30 16:06         ` Mike Frysinger
2009-09-24  1:05 ` No more bits in vm_area_struct's vm_flags KAMEZAWA Hiroyuki
2009-09-25  8:34   ` Nigel Cunningham
2009-09-25  8:40     ` KAMEZAWA Hiroyuki
2009-09-25  8:48       ` Nigel Cunningham
2009-09-25 21:09         ` Joerg Roedel
2009-09-28  2:45       ` Nigel Cunningham
2009-09-28  3:04         ` KAMEZAWA Hiroyuki
2009-09-28  3:36           ` Wu Fengguang
2009-09-28  3:57             ` KAMEZAWA Hiroyuki
2009-09-28  4:37               ` Nigel Cunningham
2009-09-28  4:51                 ` Wu Fengguang
2009-09-28  4:53                 ` KAMEZAWA Hiroyuki
2009-09-28  5:22                   ` Nigel Cunningham
2009-09-28  5:32                     ` KAMEZAWA Hiroyuki
2009-09-28 21:21                 ` Hugh Dickins [this message]
2009-09-28 21:33                   ` Nigel Cunningham
2009-09-28 15:38               ` Hugh Dickins
2009-09-28 16:14                 ` KAMEZAWA Hiroyuki
2009-09-28 21:00                   ` Hugh Dickins
2009-09-28 21:22                     ` Nigel Cunningham
2009-09-29  1:57                     ` KAMEZAWA Hiroyuki
2009-09-29 14:22                       ` Christoph Lameter
2009-10-01 10:54                         ` Hugh Dickins
2009-10-01 13:47                           ` Christoph Lameter
2009-10-01 11:38                       ` Hugh Dickins
2009-10-02  0:42                         ` KAMEZAWA Hiroyuki
2009-10-02  1:37                           ` KAMEZAWA Hiroyuki
2009-10-02  2:39                             ` KAMEZAWA Hiroyuki

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=Pine.LNX.4.64.0909282200470.11529@sister.anvils \
    --to=hugh.dickins@tiscali.co.uk \
    --cc=fengguang.wu@intel.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ncunningham@crca.org.au \
    /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).