On Wed, 8 Apr 2015, Vladimir Davydov wrote:
> Yeah, I think cache merging is a good argument for grouping memcg caches
> under /sys/kernel/slab//cgroup/. We cannot maintain symlinks
> for merged memcg caches, because when a memcg cache is created we do not
> have names of caches the new cache is m
On Wed, Apr 08, 2015 at 08:46:22AM -0500, Christoph Lameter wrote:
> On Wed, 8 Apr 2015, Vladimir Davydov wrote:
>
> > has its own copy of kmem cache. What if we decide to share the same kmem
> > cache among all memory cgroups one day? Of course, this will hardly ever
> > happen, but it is an alte
On Wed, 8 Apr 2015, Vladimir Davydov wrote:
> has its own copy of kmem cache. What if we decide to share the same kmem
> cache among all memory cgroups one day? Of course, this will hardly ever
> happen, but it is an alternative approach to implementing the same
/sys/kernel/slab already supports
On Tue, Apr 07, 2015 at 01:38:19PM -0700, Andrew Morton wrote:
> On Tue, 7 Apr 2015 16:53:18 +0300 Vladimir Davydov
> wrote:
>
> > The name of a per memcg kmem cache consists of three parts: the global
> > kmem cache name, the cgroup name, and the css id. The latter is used to
> > guarantee cach
On Tue, 7 Apr 2015 16:53:18 +0300 Vladimir Davydov
wrote:
> The name of a per memcg kmem cache consists of three parts: the global
> kmem cache name, the cgroup name, and the css id. The latter is used to
> guarantee cache name uniqueness.
>
> Since css ids are opaque to the userspace, in gener
The name of a per memcg kmem cache consists of three parts: the global
kmem cache name, the cgroup name, and the css id. The latter is used to
guarantee cache name uniqueness.
Since css ids are opaque to the userspace, in general it is impossible
to find a cache's owner cgroup given its name: ther
6 matches
Mail list logo
