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

[Christoph Lameter]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/