[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <85AFB547-D3A1-4818-AD82-FF90909775D2@linuxhacker.ru>
Date: Tue, 3 Jun 2014 22:19:12 -0400
From: Oleg Drokin <green@...uxhacker.ru>
To: David Rientjes <rientjes@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
Cody P Schafer <cody@...ux.vnet.ibm.com>,
Randy Dunlap <rdunlap@...radead.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-doc@...r.kernel.org, devel@...verdev.osuosl.org
Subject: Re: [patch] mm, pcp: allow restoring percpu_pagelist_fraction default
Hello!
On Jun 3, 2014, at 9:22 PM, David Rientjes wrote:
>
> @@ -5849,21 +5850,32 @@ int lowmem_reserve_ratio_sysctl_handler(ctl_table *table, int write,
> int percpu_pagelist_fraction_sysctl_handler(ctl_table *table, int write,
> void __user *buffer, size_t *length, loff_t *ppos)
> {
> + const int old_percpu_pagelist_fraction = percpu_pagelist_fraction;
> struct zone *zone;
> - unsigned int cpu;
> int ret;
>
> ret = proc_dointvec_minmax(table, write, buffer, length, ppos);
> - if (!write || (ret < 0))
> + if (!write || ret < 0)
> return ret;
>
> + /* Sanity checking to avoid pcp imbalance */
> + if (percpu_pagelist_fraction &&
> + percpu_pagelist_fraction < MIN_PERCPU_PAGELIST_FRACTION) {
> + percpu_pagelist_fraction = old_percpu_pagelist_fraction;
> + return -EINVAL;
> + }
> +
> + /* No change? */
> + if (percpu_pagelist_fraction == old_percpu_pagelist_fraction)
> + return 0;
> +
> mutex_lock(&pcp_batch_high_lock);
> for_each_populated_zone(zone) {
> - unsigned long high;
> - high = zone->managed_pages / percpu_pagelist_fraction;
> + unsigned int cpu;
> +
> for_each_possible_cpu(cpu)
> - pageset_set_high(per_cpu_ptr(zone->pageset, cpu),
> - high);
> + pageset_set_high_and_batch(zone,
> + per_cpu_ptr(zone->pageset, cpu));
BTW, I just realized this version is racy (as was the previous one).
A parallel writer could write a value of 0 while we are in the middle of pageset_set_high_and_batch
and it's possible that'll result in division by zero still.
Also it's possible an incorrect value might set for some of the zones.
I imagine we might want to expand the lock area all the way up to before the proc_dointvec_minmax call jsut to be extra safe.
> }
> mutex_unlock(&pcp_batch_high_lock);
> return 0;
Bye,
Oleg--
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/
Powered by blists - more mailing lists