lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0710312221140.26444@schroedinger.engr.sgi.com>
Date:	Wed, 31 Oct 2007 22:25:10 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Paul Jackson <pj@....com>
cc:	rientjes@...gle.com, Lee.Schermerhorn@...com,
	linux-kernel@...r.kernel.org, ak@...e.de
Subject: Re: [RFC] cpuset relative memory policies - second choice

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
is available.

>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ