On Thu, Oct 25, 2012 at 02:37:07PM -0700, Andrew Morton wrote:

On Fri, 26 Oct 2012 00:22:51 +0300
"Kirill A. Shutemov" [off-list ref] wrote:

quoted

On Thu, Oct 25, 2012 at 02:05:24PM -0700, Andrew Morton wrote:

quoted

hm.  It's odd that the kernel didn't try to shrink slabs in this case. 
Why didn't it??

nr_to_scan == 0 asks for the fast path. shrinker callback can shink, if
it thinks it's good idea.

What nr_objects does your shrinker return in that case?

HPAGE_PMD_NR if hzp is freeable, otherwise 0.

quoted

quoted

quoted

I also tried another scenario: usemem -n16 100M -r 1000. It creates real
memory pressure - no easy reclaimable memory. This time callback called
with nr_to_scan > 0 and we freed hzp. Under pressure we fails to allocate
hzp and code goes to fallback path as it supposed to.

Do I need to check any other scenario?

I'm thinking that if we do hit problems in this area, we could avoid
freeing the hugepage unless the scan_control.priority is high enough. 
That would involve adding a magic number or a tunable to set the
threshold.

What about ratelimit on alloc path to force fallback if we allocate
to often? Is it good idea?

mmm...  ratelimit via walltime is always a bad idea.  We could
ratelimit by "number of times the shrinker was called", and maybe that
would work OK, unsure.

It *is* appropriate to use sc->priority to be more reluctant to release
expensive-to-reestablish objects.  But there is already actually a
mechanism in the shrinker code to handle this: the shrink_control.seeks
field.  That was originally added to provide an estimate of "how
expensive will it be to recreate this object if we were to reclaim it".
So perhaps we could generalise that a bit, and state that the zero
hugepage is an expensive thing.

I've proposed DEFAULT_SEEKS * 4 already.

I don't think the shrink_control.seeks facility had ever been used much,
so it's possible that it is presently mistuned or not working very
well.

Yeah, non-default .seeks is only in kvm mmu_shrinker and in few places in
staging/android/.

-- 
 Kirill A. Shutemov