Containers and /proc/sys/vm/drop_caches

Matt Helsley matthltc at
Thu Jan 6 14:08:41 PST 2011

On Thu, Jan 06, 2011 at 01:50:05PM -0800, Dave Hansen wrote:
> On Thu, 2011-01-06 at 13:43 -0800, Matt Helsley wrote:
> > That said, the more important question is why should we provide
> > drop_caches inside a container? My understanding is it's largely a
> > workload-debugging tool and not something meant to truly solve
> > problems. If that's the case then we shouldn't provide it at all or it
> > should actually interfere with the host cache. 
> Yeah, what's the problem that you're solving with drop_caches?  The odds
> are, there's a better way.
> That said, it _might_ be worth doing things like dropping (inode or
> dentry) caches per-sb.  That's a much better fit than using big, ugly,
> loosely-defined, system-wide knobs like drop_caches.

Yup. Since many containers will have their own mount namespaces with
separate sbs it's a more reasonable approximation of per-container
dropping of caches.

> Also, unless we start giving containers real ownership of devices or
> partitions, it's going to be pretty darn hard to let things clear caches
> in a meaningful way.  What if one container wants an object cleared
> while another doesn't?

Good point. First reaction: we'd want to keep it cached if any of the
containers want it. But even that's a bad policy under certain
circumstances containers (aka VPS) might be used for.

Is drop_caches well-defined? IOW would it be permissible to
not actually drop all or any of the cache entries or to do nothing and
still report success instead of, say, EPERM, to a container?

	-Matt Helsley

More information about the Containers mailing list