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? Cheers, -Matt Helsley _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
