On Thu, Oct 03, 2019 at 12:47:41PM +0200, Michal Koutný wrote:
> On Wed, Oct 02, 2019 at 10:00:07PM +0900, Suleiman Souhlal
> wrote:
> > kmem.slabinfo has been absolutely invaluable for debugging, in my
> > experience.
> > I am however not aware of any automation based on it.
> My experience is
On Wed, Oct 02, 2019 at 10:00:07PM +0900, Suleiman Souhlal
wrote:
> kmem.slabinfo has been absolutely invaluable for debugging, in my experience.
> I am however not aware of any automation based on it.
My experience is the same. However, the point is that this has been
exposed since ages, so the
On Wed, Oct 2, 2019 at 11:09 AM Roman Gushchin wrote:
>
> On Tue, Oct 01, 2019 at 05:12:02PM +0200, Michal Koutný wrote:
> > On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin
> > wrote:
> > > Roman Gushchin (14):
> > > [...]
> > > mm: memcg/slab: use one set of kmem_caches for all memor
On Tue, Oct 01, 2019 at 05:12:02PM +0200, Michal Koutný wrote:
> On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin wrote:
> > Roman Gushchin (14):
> > [...]
> > mm: memcg/slab: use one set of kmem_caches for all memory cgroups
> From that commit's message:
>
> > 6) obsoletes kmem.slabinf
On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin wrote:
> Roman Gushchin (14):
> [...]
> mm: memcg/slab: use one set of kmem_caches for all memory cgroups
From that commit's message:
> 6) obsoletes kmem.slabinfo cgroup v1 interface file, as there are
> no per-memcg kmem_caches anymore
On Fri, Sep 20, 2019 at 06:10:11AM +0900, Suleiman Souhlal wrote:
> On Fri, Sep 20, 2019 at 1:22 AM Roman Gushchin wrote:
> >
> > On Thu, Sep 19, 2019 at 10:39:18PM +0900, Suleiman Souhlal wrote:
> > > On Fri, Sep 6, 2019 at 6:57 AM Roman Gushchin wrote:
> > > > The patchset has been tested on a
On Fri, Sep 20, 2019 at 1:22 AM Roman Gushchin wrote:
>
> On Thu, Sep 19, 2019 at 10:39:18PM +0900, Suleiman Souhlal wrote:
> > On Fri, Sep 6, 2019 at 6:57 AM Roman Gushchin wrote:
> > > The patchset has been tested on a number of different workloads in our
> > > production. In all cases, it save
On Thu, Sep 19, 2019 at 10:39:18PM +0900, Suleiman Souhlal wrote:
> On Fri, Sep 6, 2019 at 6:57 AM Roman Gushchin wrote:
> > The patchset has been tested on a number of different workloads in our
> > production. In all cases, it saved hefty amounts of memory:
> > 1) web frontend, 650-700 Mb, ~42%
On Fri, Sep 6, 2019 at 6:57 AM Roman Gushchin wrote:
> The patchset has been tested on a number of different workloads in our
> production. In all cases, it saved hefty amounts of memory:
> 1) web frontend, 650-700 Mb, ~42% of slab memory
> 2) database cache, 750-800 Mb, ~35% of slab memory
> 3) d
On Tue, Sep 17, 2019 at 03:48:57PM -0400, Waiman Long wrote:
> On 9/5/19 5:45 PM, Roman Gushchin wrote:
> > The existing slab memory controller is based on the idea of replicating
> > slab allocator internals for each memory cgroup. This approach promises
> > a low memory overhead (one pointer per
On 9/5/19 5:45 PM, Roman Gushchin wrote:
> The existing slab memory controller is based on the idea of replicating
> slab allocator internals for each memory cgroup. This approach promises
> a low memory overhead (one pointer per page), and isn't adding too much
> code on hot allocation and release
11 matches
Mail list logo
