* Re: [tip:numa/core] mm: Count the number of pages affected in change_protection()
[not found] <tip-a9463d90124af069b9b58a276acc46c00054d722@git.kernel.org>
@ 2012-11-14 17:26 ` Andrew Morton
0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2012-11-14 17:26 UTC (permalink / raw)
To: linux-kernel, mingo, hpa, a.p.zijlstra, torvalds, riel, akpm,
aarcange, mgorman, tglx
Cc: tip-bot for Peter Zijlstra, linux-tip-commits, hpa, mingo,
torvalds, riel, aarcange, mgorman, tglx
On Wed, 14 Nov 2012 06:25:56 -0800 tip-bot for Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> mm: Count the number of pages affected in change_protection()
>
> This will be used by three kinds of purposes:
>
> - to optimize mprotect()
>
> - to speed up working set scanning for working set areas that
> have not been touched
>
> - to more accurately scan per real working set
>
> No change in functionality from this patch.
Seems simple, cheap and useful.
A bit lacking in interface comments though. In particular, does the
return value (which is in units of PAGE_SIZE pages) represent the
number of pages which were inspected, or the number of pages which
actually had their permissions modified?
>From a quick look, it seems the answer is both. Or neither. If a
page's protection was written to but unaltered, that counts as a "1".
But if a pmd couldn't be locked via __pmd_trans_huge_lock(), that
counts as a "0".
Anyway, please have a think about it, and describe exactly what these
return values mean?
^ permalink raw reply [flat|nested] only message in thread