Re: [RFC] cpuset relative memory policies - second choice
From: Christoph Lameter
Date: Thu Nov 01 2007 - 01:25:26 EST
On Wed, 31 Oct 2007, Paul Jackson wrote:
> Christoph, replying to pj:
> > > Well, the mpol_nodemask_mode already is char. So I guess you're
> > > asking if we should change 'policy' to type char as well.
> > Right.
> Ok - but why?
> I don't see that it matters whether policy is short or char.
It looks strange if they have different. Maybe use u8 for both?
> > s/numactl/libnuma/
> So you would rather have libnuma manage this flag?
> As opposed to what else managing it? I'm still a tad confused on
> what you're suggesting on this one.
You are managing it in the task struct. No need to. libnuma can handle it.
> > But that is only done in libnuma. User code does not call this directly.
> I disagree.
> There are several mempolicy interfaces in use, including at least:
> 1) libnuma, which in turn is based on (5), below
> 2) the numactl command line utility (based on libnuma)
> 3) libcpuset (which has its own modest mempolicy interface)
These are no problem 1/2 are libnuma. No current version of libcpuset
> 4) the glibc mbind/set_mempolicy/get_mempolicy wrappers, in C code
> 5) roll your own mbind/*_mempolicy system call wrappers, in C code
Those exist? Never seen that.
> With the mode bit as in my patch, there are fewer places in the user
> code that have to be gotten just right. With your way, each and
> every mbind and *_mempolicy call has to be hacked with the new flag
> if one is going to use the new nodemask bit numbering. Some of these
Yes and that makes sure it is thought through and done right.
> Perhaps that's the way to go:
> mbind2, get_mempolicy2, and set_mempolicy2.
That would be okay from the backwards compat standpoint.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/