Re: [PATCH 1/2] mm: use slab size in the slab shrinking ratio calculation

From: Dave Chinner <david@fromorbit.com>
To: Josef Bacik <josef@toxicpanda.com>
Cc: Minchan Kim <minchan@kernel.org>,
	hannes@cmpxchg.org, riel@redhat.com, akpm@linux-foundation.org,
	linux-mm@kvack.org, kernel-team@fb.com,
	Josef Bacik <jbacik@fb.com>,
	mhocko@kernel.org, cl@linux.com
Subject: Re: [PATCH 1/2] mm: use slab size in the slab shrinking ratio calculation
Date: Thu, 6 Jul 2017 09:30:06 +1000	[thread overview]
Message-ID: <20170705233006.GU17542@dastard> (raw)
In-Reply-To: <20170705133344.GB16179@destiny>

On Wed, Jul 05, 2017 at 09:33:45AM -0400, Josef Bacik wrote:
> On Wed, Jul 05, 2017 at 08:57:58AM +1000, Dave Chinner wrote:
> > My suggestion of allocation based aging callbacks is something for
> > specific caches to be able to run based on their own or the users
> > size/growth/performance constraints. It's independent of memory
> > reclaim behaviour and so can be a strongly biased as the user wants.
> > Memory reclaim will just maintain whatever balance that exists
> > between the different caches as a result of the subsystem specific
> > aging callbacks.
> > 
> 
> Ok so how does a scheme like this look?  The shrinking stuff can be relatively
> heavy because generally speaking it's always run asynchronously by kswapd, so
> the only latency it induces to normal workloads is the CPU time it takes away
> from processes we care about.
> 
> With an aging callback at allocation time we're inducing latency for the user at
> allocation time.  So we want to do as little as possible here, but what do we
> need to determine if there's something to do?  Do we just have a static "I'm
> over limit X objects, start a worker thread to check if we need to reclaim"?  Or
> do we have it be actually smart, checking the overall count and checking it
> against some configurable growth rate?  That's going to be expensive on a per
> allocation basis.
> 
> I'm having a hard time envisioning how this works that doesn't induce a bunch of
> latency.

I was thinking the aging would also be async, like kswapd, and the
only thing the allocation does is accounting. THe actual aging scans
don't need to be done in the foreground and get the in way of the
current allocation because aging doesn't need precise control or
behaviour...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>