Re: [PATCH] Use MPOL_INTERLEAVE for tmpfs files

From: Hugh Dickins
Date: Wed Nov 10 2004 - 09:36:06 EST

On Tue, 9 Nov 2004, Brent Casavant wrote:
> On Tue, 9 Nov 2004, Hugh Dickins wrote:
> > Doesn't quite play right with what was my "NULL sbinfo" convention.
> Howso? I thought it played quite nicely with it. We've been using
> NULL sbinfo as an indicator that an inode is from tmpfs rather than
> from SysV or /dev/zero. Or at least that's the way my brain was
> wrapped around it.

That was the case you cared about, but remember I extended yours so
that tmpfs mounts could also suppress limiting, and get NULL sbinfo.

> The NULL sbinfo scheme worked perfectly for me, with very little hassle.

Yes, it would have worked just right for the important cases.

> > 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.
> Is this something imminent, or on the "someday" queue? Just asking
> because I'd like to avoid doing additional work that might get thrown
> away soon.

I understand your concern ;) I'm working on it, today or tomorrow.

> > 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.
> Well, the only thing preventing this is that I stuck the flag into
> sbinfo, since it's an filesystem-wide setting. I don't see any reason
> we couldn't add a new flag in the inode info flag field instead. I
> think there would also be some work to set pvma.vm_end more precisely
> (in mpol_shared_policy_init()) in the SysV case.

It's not a matter of where to store the info, it's that we don't have
a user interface for remounting something that's not mounted anywhere.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at