linux-kernel - Re: [PATCH 1/2] mm: page allocator: Adjust the per-cpu counter threshold when memory is low

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, 9 Nov 2010 10:48:13 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Mel Gorman <mel@....ul.ie>, Shaohua Li <shaohua.li@...el.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Rientjes <rientjes@...gle.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH 1/2] mm: page allocator: Adjust the per-cpu counter
 threshold when memory is low

On Fri, 29 Oct 2010, Andrew Morton wrote:

> > To match the existing maximum which I assume is due to the deltas being
> > stored in a s8.
>
> hm, OK.  So (CHAR_MAX-2) would be a tad clearer, only there's no
> CHAR_MAX and "2" remains mysterious ;)

inc/dec_zone_page_state first increments (allows compiler to generate a
RMV instruction, hmmm... there we could use this cpu....) and then checks
if we are beyond the threshold. So the maximum value has to be below
CHAR_MAX. 125 is the next value that looks somewhat sane as a limit. We
could use CHAR_MAX if we change the comparison logic for the threshhold.

> I do go on about code comments a lot lately.  Eric D's kernel just
> crashed because we didn't adequately comment first_zones_zonelist()
> so I'm feeling all vindicated!

We should not have done the change to add the nodemask to
first_zones_zonelist but instead added a new function. Now the function
has two different ways of behaving.

> I don't really buy that.  The cache footprint will be increased by a
> max of one cacheline (for zone->stat_threshold) and the cache footprint
> will be actually reduced in the much larger percpu area (depending on
> alignment and padding and stuff).

It will increase by one cacheline per zone in use. Large systems have lots
of zones which increases the effect.

The vmstat functions are often used as primitives in various critical code
paths. The cache footprint needs to be kept as low as possible.
--
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/