All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Brent Casavant <bcasavan@sgi.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>, Andi Kleen <ak@suse.de>,
	"Adam J. Richter" <adam@yggdrasil.com>, <colpatch@us.ibm.com>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH] Use MPOL_INTERLEAVE for tmpfs files
Date: Tue, 9 Nov 2004 19:04:25 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0411091824070.5130-100000@localhost.localdomain> (raw)
In-Reply-To: <Pine.SGI.4.58.0411081314160.101942@kzerza.americas.sgi.com>

On Mon, 8 Nov 2004, Brent Casavant wrote:
> On Wed, 3 Nov 2004, Martin J. Bligh wrote:
> 
> > Matt has volunteered to write the mount option for this, so let's hold
> > off for a couple of days until that's done.
> 
> I had the time to do this myself.  Updated patch attached below.

Looks pretty good to me.

Doesn't quite play right with what was my "NULL sbinfo" convention.
Given this mpol patch of yours, and Adam's devfs patch, it's becoming
clear that my "NULL sbinfo" was unhelpful, making life harder for both
of you to add things into the tmpfs superblock - unchanged since 2.4.0,
as soon as I mess with it, people come up with valid new uses for it.

Not to say that your patch or Adam's will go further (I've no objection
to the way Adam is using tmpfs, but no opinion on the future of devfs),
but they're two hints that I should rework that to get out of people's
way.  I'll do a patch for that, then another something like yours on
top, for you to go back and check.

I think the option should be "mpol=interleave" rather than just
"interleave", who knows what baroque mpols we might want to support
there in future?

I'm irritated to realize that we can't change the default for SysV
shared memory or /dev/zero this way, because that mount is internal.
But neither you nor Andi were wanting that, so okay, never mind;
could use his sysctl instead if the need emerges.

At one time (August) you were worried about MPOL_INTERLEAVE
overloading node 0 on small files - is that still a worry?
Perhaps you skirt that issue in recommending this option
for use with giant files.

There are quite a lot of mpol patches flying around, aren't there?
>From Ray Bryant and from Steve Longerbeam.  Would this tmpfs patch
make (adaptable) sense if we went either or both of those ways - or
have they been knocked on the head?  I don't mean in the details
(I think one of them does away with the pseudo-vma stuff - great!),
but in basic design - would your mount option mesh together well
with them, or would it be adding a further layer of confusion?

Hugh


WARNING: multiple messages have this Message-ID (diff)
From: Hugh Dickins <hugh@veritas.com>
To: Brent Casavant <bcasavan@sgi.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>, Andi Kleen <ak@suse.de>,
	"Adam J. Richter" <adam@yggdrasil.com>,
	colpatch@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH] Use MPOL_INTERLEAVE for tmpfs files
Date: Tue, 9 Nov 2004 19:04:25 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0411091824070.5130-100000@localhost.localdomain> (raw)
In-Reply-To: <Pine.SGI.4.58.0411081314160.101942@kzerza.americas.sgi.com>

On Mon, 8 Nov 2004, Brent Casavant wrote:
> On Wed, 3 Nov 2004, Martin J. Bligh wrote:
> 
> > Matt has volunteered to write the mount option for this, so let's hold
> > off for a couple of days until that's done.
> 
> I had the time to do this myself.  Updated patch attached below.

Looks pretty good to me.

Doesn't quite play right with what was my "NULL sbinfo" convention.
Given this mpol patch of yours, and Adam's devfs patch, it's becoming
clear that my "NULL sbinfo" was unhelpful, making life harder for both
of you to add things into the tmpfs superblock - unchanged since 2.4.0,
as soon as I mess with it, people come up with valid new uses for it.

Not to say that your patch or Adam's will go further (I've no objection
to the way Adam is using tmpfs, but no opinion on the future of devfs),
but they're two hints that I should rework that to get out of people's
way.  I'll do a patch for that, then another something like yours on
top, for you to go back and check.

I think the option should be "mpol=interleave" rather than just
"interleave", who knows what baroque mpols we might want to support
there in future?

I'm irritated to realize that we can't change the default for SysV
shared memory or /dev/zero this way, because that mount is internal.
But neither you nor Andi were wanting that, so okay, never mind;
could use his sysctl instead if the need emerges.

At one time (August) you were worried about MPOL_INTERLEAVE
overloading node 0 on small files - is that still a worry?
Perhaps you skirt that issue in recommending this option
for use with giant files.

There are quite a lot of mpol patches flying around, aren't there?
>From Ray Bryant and from Steve Longerbeam.  Would this tmpfs patch
make (adaptable) sense if we went either or both of those ways - or
have they been knocked on the head?  I don't mean in the details
(I think one of them does away with the pseudo-vma stuff - great!),
but in basic design - would your mount option mesh together well
with them, or would it be adding a further layer of confusion?

Hugh

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

  parent reply	other threads:[~2004-11-09 19:04 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-02  1:07 [PATCH] Use MPOL_INTERLEAVE for tmpfs files Brent Casavant
2004-11-02  1:07 ` Brent Casavant
2004-11-02  1:43 ` Dave Hansen
2004-11-02  1:43   ` Dave Hansen
2004-11-02  9:13 ` Andi Kleen
2004-11-02  9:13   ` Andi Kleen
2004-11-02 15:46 ` Martin J. Bligh
2004-11-02 15:46   ` Martin J. Bligh
2004-11-02 15:55   ` Andi Kleen
2004-11-02 15:55     ` Andi Kleen
2004-11-02 16:55     ` Martin J. Bligh
2004-11-02 16:55       ` Martin J. Bligh
2004-11-02 22:17       ` Brent Casavant
2004-11-02 22:17         ` Brent Casavant
2004-11-02 22:51         ` Martin J. Bligh
2004-11-02 22:51           ` Martin J. Bligh
2004-11-03  1:12           ` Brent Casavant
2004-11-03  1:12             ` Brent Casavant
2004-11-03  1:30             ` Martin J. Bligh
2004-11-03  8:44           ` Hugh Dickins
2004-11-03  8:44             ` Hugh Dickins
2004-11-03  9:01             ` Andi Kleen
2004-11-03  9:01               ` Andi Kleen
2004-11-03 16:32               ` Brent Casavant
2004-11-03 16:32                 ` Brent Casavant
2004-11-03 21:00                 ` Martin J. Bligh
2004-11-03 21:00                   ` Martin J. Bligh
2004-11-08 19:58                   ` Brent Casavant
2004-11-08 19:58                     ` Brent Casavant
2004-11-08 20:57                     ` Martin J. Bligh
2004-11-08 20:57                       ` Martin J. Bligh
2004-11-09 19:04                     ` Hugh Dickins [this message]
2004-11-09 19:04                       ` Hugh Dickins
2004-11-09 20:09                       ` Martin J. Bligh
2004-11-09 20:09                         ` Martin J. Bligh
2004-11-09 21:08                         ` Hugh Dickins
2004-11-09 21:08                           ` Hugh Dickins
2004-11-09 22:07                           ` Martin J. Bligh
2004-11-09 22:07                             ` Martin J. Bligh
2004-11-10  2:41                       ` Brent Casavant
2004-11-10  2:41                         ` Brent Casavant
2004-11-10 14:20                         ` Hugh Dickins
2004-11-10 14:20                           ` Hugh Dickins
2004-11-11 19:48                       ` Hugh Dickins
2004-11-11 19:48                         ` Hugh Dickins
2004-11-11 23:10                         ` Brent Casavant
2004-11-11 23:10                           ` Brent Casavant
2004-11-15 22:07                         ` Brent Casavant
2004-11-15 22:07                           ` Brent Casavant

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.44.0411091824070.5130-100000@localhost.localdomain \
    --to=hugh@veritas.com \
    --cc=adam@yggdrasil.com \
    --cc=ak@suse.de \
    --cc=bcasavan@sgi.com \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@aracnet.com \
    /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.