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:	Wed, 2 May 2007 00:25:38 -0700
From:	Paul Jackson <pj@....com>
To:	"Paul Menage" <menage@...gle.com>
Cc:	rientjes@...gle.com, torvalds@...ux-foundation.org,
	clameter@...ulhu.engr.sgi.com, linux-kernel@...r.kernel.org
Subject: Re: [patch] cpusets: allow empty {cpus,mems}_allowed to be set for
 unpopulated cpuset

Paul M wrote:
> Otherwise the only way to reclaim
> the node for a different sibling is to delete the cpuset.

Ah - I just made sense of that sentence.

It means that if a particular memory node is in one cpuset, and you'd
like to have it in another cpuset instead, then with the existing
kernel code, you had to special case the situation where this memory
node was the last node in the original cpuset - deleting the cpuset
just to do this.

Yeah - I have never given much thought to moving memory nodes from one
cpuset to another.  No good reason; it just didn't happen to be a
common operation for the uses of cpusets I cared about.

I still have this niggling fear that there was something that passed my
view, years ago, that this proposed change (to allow unpopulating a
cpuset) will break.

But I'll be damned if I can remember what it was.

Ok ... if this patch passes my cpuset_test (guess I'll try that now)
then I'm ok with this patch.

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