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]

Message-ID: <alpine.DEB.0.9999.0711011153590.21823@chino.kir.corp.google.com>
Date:	Thu, 1 Nov 2007 12:00:56 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Jackson <pj@....com>
cc:	Christoph Lameter <clameter@....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:

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

That code is going to have to be hacked anyway to use the new nodemask 
semantics, so it can easily add a flag to the set_mempolicy() call for the 
system-wide node numbering.  This then only requires a small addition to 
the documentation: use MPOL_F_MODE_SYS_WIDE for system-wide node numbering 
that isn't constrained to your cpuset.

> Some of these
> calls might be inside other routines or libraries that aren't readily
> available to be examined or changed.  If you miss one, or forget to
> add one when adding more mbind or *_mempolicy calls in the future,
> then you have a nasty lurking hidden performance bug due to misplaced
> pages in certain configurations.  That too is a serious maintenance
> nightmare, as I've already tried to describe.
> 

That's a very legitimate concern, but those libraries will eventually need 
to be made to support this new extention anyway.  They will be modified 
just like we're modifying the kernel once people want to start using the 
different nodemask semantics.  As mempolicy modes become more popular, 
those libraries are going to start accepting custom mode flags to pass to 
their set_mempolicy() wrappers that will get OR'd with the mempolicy mode 
that is used.  It will be the natural progression of how mempolicies are 
supported in userspace.

		David
-
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/