Re: [PATCH v4 10/10] thp: implement refcounting for huge zero page

["Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]

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@shutemov.name> 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]