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" <kirill@xxxxxxxxxxxxx> wrote: > > > On Thu, Oct 25, 2012 at 02:05:24PM -0700, Andrew Morton wrote: > > > 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. > > > > 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
Attachment:
signature.asc
Description: Digital signature