linux-kernel - Re: Some thoughts on 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: <20070619142344.db0f636c.pj@sgi.com>
Date:	Tue, 19 Jun 2007 14:23:44 -0700
From:	Paul Jackson <pj@....com>
To:	Lee Schermerhorn <Lee.Schermerhorn@...com>
Cc:	clameter@....com, linux-mm@...ck.org, wli@...omorphy.com,
	linux-kernel@...r.kernel.org
Subject: Re: Some thoughts on memory policies

> The current memory policy APIs can work in such a "containerized"
> environment if we can reconcile the policy APIs' notion of nodes with
> the set of nodes that container allows.  Perhaps we need to revisit the
> "cpumemset" proposal that provides a separate node id namespace in each
> container/cpuset.

Currently, we (SGI) do this for our systems using user level library
code.

Even though that library code is LGPL licensed, it's still far less
widely distributed than the Linux kernel.  Container relative numbering
support directly in the kernel might make sense; though it would be
very challenging to provide that without breaking any existing API's
such as sched_setaffinity, mbind, set_mempolicy and various /proc
files that provide only system-wide numbering.

The advantage I had doing cpuset relative cpu and mem numbering in a
user library was that I could invent new API's that were numbered
relatively from day one.

So ... I'd likely be supportive of cpuset (or container) relative
numbering support in the kernel ... if someone can figure out how to do
it without breaking existing API's left and right.

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