linux-kernel - Re: [PATCH 00/10] mm: Linux VM Infrastructure to support Memory Power Management

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: <20110528005640.9076c0b1.akpm@linux-foundation.org>
Date:	Sat, 28 May 2011 00:56:40 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ankita Garg <ankita@...ibm.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	svaidy@...ux.vnet.ibm.com, thomas.abraham@...aro.org
Subject: Re: [PATCH 00/10] mm: Linux VM Infrastructure to support Memory
 Power Management

On Fri, 27 May 2011 18:01:28 +0530 Ankita Garg <ankita@...ibm.com> wrote:

> This patchset proposes a generic memory regions infrastructure that can be
> used to tag boundaries of memory blocks which belongs to a specific memory
> power management domain and further enable exploitation of platform memory
> power management capabilities.

A couple of quick thoughts...

I'm seeing no estimate of how much energy we might save when this work
is completed.  But saving energy is the entire point of the entire
patchset!  So please spend some time thinking about that and update and
maintain the [patch 0/n] description so others can get some idea of the
benefit we might get from all of this.  That estimate should include an
estimate of what proportion of machines are likely to have hardware
which can use this feature and in what timeframe.

IOW, if it saves one microwatt on 0.001% of machines, not interested ;)

Also, all this code appears to be enabled on all machines?  So machines
which don't have the requisite hardware still carry any additional
overhead which is added here.  I can see that ifdeffing a feature like
this would be ghastly but please also have a think about the
implications of this and add that discussion also.  

If possible, it would be good to think up some microbenchmarks which
probe the worst-case performance impact and describe those and present
the results.  So others can gain an understanding of the runtime costs.

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