linux-kernel - Re: [RFC] bitmap onto and fold operators for mempolicy extensions

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] [day] [month] [year] [list]

Date:	Tue, 19 Feb 2008 00:05:29 -0600
From:	Paul Jackson <pj@....com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Lee.Schermerhorn@...com, mel@....ul.ie, ak@...e.de,
	linux-kernel@...r.kernel.org, ray-lk@...rabbit.org,
	kosaki.motohiro@...fujitsu.com, akpm@...ux-foundation.org,
	clameter@....com
Subject: Re: [RFC] bitmap onto and fold operators for mempolicy extensions

David wrote:
> So what is the MPOL_F_RELATIVE_NODES behavior?  Is it a combination of 
> nodes_onto() and nodes_fold()?

MPOL_F_RELATIVE_NODES should always combination of nodes_onto() and
nodes_fold().

The reason I say that is consistency with the end cases.  That is,
we need fold in the case that no requested nodes have numbers
smaller than the weight of the cpusets mems_allowed.  At the opposite
extreme, when -all- requested node numbers are smaller than the weight
of mems_allowed, fold has no affect, so it's fine to use there.  And
for the in between cases, when some requested nodes are smaller and
some not, fold is one possible reasonable answer.  So use it everywhere
for consistency.

> So it's easy enough to do this:
> 	case MPOL_INTERLEAVE:
> 		if (flags & MPOL_F_RELATIVE_NODES) {
> 			nodes_onto(pol->v.nodes, pol->user_nodemask,
> 				   cpuset_context_nmask);
> 			if (nodes_empty(pol->v.nodes))

I hate any more special cases than I have to have -- so not that way.

> But what if we require a combination?  Say the user asked for a policy of 
> MPOL_INTERLEAVE | MPOL_F_RELATIVE_NODES over nodes 4-8 in a cpuset 
> constrained to mems 0-7?  Should the resultant be 0,4-7 (combination of 
> nodes_onto() and nodes_fold()) or simply be 4-7 (just nodes_onto())?

All fold, all the time ;).  So this one should be 0,4-7.

> And what if the MPOL_INTERLEAVE | MPOL_F_RELATIVE_NODES nodemask is 0,4-8 
> in the same cpuset constrained to mems 0-7?  Should the resultant be
> 
>  - 0,4-7 (nodes_onto() and nodes_fold()),
> 
>  - 0,4-7 (just nodes_onto()), or
> 
>  - 0-1,4-7 (nodes_onto(), nodes_fold(), and shift)?
> 
> The last option, 0-1,4-7, is the only one that preserves the same weight 
> as the relative nodemask.

Again, 0,4-7.

Weight preservation is not a goal here, and would require special cases.

If someone crams a five pound cpuset relative memory policy into a two
poound cpuset, they will likely loose weight.  What matters in that
case is that things plod along without too much distress, and that
when the job is restored to a proper size cpuset, its memory policies
recover their full health.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
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/