linux-kernel - Re: [PATCH 5/7] Add /proc trigger for memory compaction

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, 20 Jan 2010 20:53:49 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	David Rientjes <rientjes@...gle.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Adam Litke <agl@...ibm.com>, Avi Kivity <avi@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 5/7] Add /proc trigger for memory compaction

On Wed, Jan 20, 2010 at 12:12:55PM -0600, Christoph Lameter wrote:
> On Wed, 20 Jan 2010, Mel Gorman wrote:
> 
> > True, although the per-node structures are only available on NUMA making
> > it necessary to have two interfaces. The per-node one is handy enough
> > because it would be just
> >
> > /sys/devices/system/node/nodeX/compact_node
> > 	When written to, this node is compacted by the writing process
> >
> > But there does not appear to be a "good" way of having a non-NUMA
> > interface. /sys/devices/system/node does not exist .... Does anyone
> > remember why !NUMA does not have a /sys/devices/system/node/node0? Is
> > there a good reason or was there just no point?
> 
> We could create a fake node0 for the !NUMA case I guess?

I would like to but I have the same concerns as you about programs or scripts
assuming the existence of /sys/devices/system/node/ imples NUMA.

> Dont see a major
> reason why not to do it aside from scripts that may check for the presence
> of the file to switch to a "NUMA" mode.
> 

That would suck royally and unfortunately it's partly the case with libnuma
at least. Well, not the library itself but one of the utilities.

numa_available() is implemented by checking the return value of get_mempolicy()
so it's ok.

It checks the max configured node by parsing the contents of the
/sys/devices/system/node/ directory so that should also be ok as long as
the UMA node is 0.

However, the numastat script is a perl script that makes assumptions on
NUMA versus UMA depending on the existence of the sysfs directory. If it
exists, it parses numastat. While this would be faked as well, we're
talking about adding a fair amount of fakery in there and still end up
with a behaviour change. Previously, the script would have identified
the system was not NUMA aware and afterwards, it prints out meaningless
values.

Not sure how great an option that is :(

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/