linux-kernel - Re: [RFC] cpuset relative memory policies

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]

Date:	Thu, 1 Nov 2007 06:07:33 -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:

> > You are managing it in the task struct. No need to. libnuma can handle it.
> 
> No - as noted, not all mempolicy system calls go via libnuma.

Well then show me.

> > No current version of libcpuset is available.
> 
> Wrong.  It has not received wide publication yet, but it has been
> provided to various others under LGPL license.

The last version that I remember was for 2.4.x.

>     A search of some old SGI release software sitting on an internal
>     server just now suggests that products with names including histx,
>     gru, libmpi and pcp might be directly invoking these system calls
>     ... I didn't actually examine the source to determine whether
>     they really use these direct calls -- just got a grep hit.

A good argument to leave the API unchanged and not create magic task 
flags.

> > > 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.
> 
> Maybe for you.  Not for the rest of us error prone mere mortals.

> Forcing coders to specify the same detail in multiple places, when
> there is no way to validate their consistency, doesn't force them
> to think or do it right.  It increases the error rate due to

There are always wrappers for system calls. The flags will be set in 
these.
-
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/