On Mon, Jun 30, 2014 at 10:49:03AM -0500, Christoph Lameter wrote:
> On Fri, 27 Jun 2014, Joonsoo Kim wrote:
>
> > Christoph,
> > Is it tolerable result for large scale system? Or do we need to find
> > another solution?
>
>
> The overhead is pretty intense but then this is a rare event I
On Mon, Jun 30, 2014 at 10:49:03AM -0500, Christoph Lameter wrote:
On Fri, 27 Jun 2014, Joonsoo Kim wrote:
Christoph,
Is it tolerable result for large scale system? Or do we need to find
another solution?
The overhead is pretty intense but then this is a rare event I guess?
Yes,
On Fri, 27 Jun 2014, Joonsoo Kim wrote:
> Christoph,
> Is it tolerable result for large scale system? Or do we need to find
> another solution?
The overhead is pretty intense but then this is a rare event I guess?
It seems that it is much easier on the code and much faster to do the
periodic
On Fri, 27 Jun 2014, Joonsoo Kim wrote:
Christoph,
Is it tolerable result for large scale system? Or do we need to find
another solution?
The overhead is pretty intense but then this is a rare event I guess?
It seems that it is much easier on the code and much faster to do the
periodic
On Wed, Jun 25, 2014 at 05:45:45PM +0400, Vladimir Davydov wrote:
> On Tue, Jun 24, 2014 at 04:38:41PM +0900, Joonsoo Kim wrote:
> > On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
> > And, you said that this way of implementation would be slow because
> > there could be many
On Wed, Jun 25, 2014 at 05:45:45PM +0400, Vladimir Davydov wrote:
On Tue, Jun 24, 2014 at 04:38:41PM +0900, Joonsoo Kim wrote:
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
And, you said that this way of implementation would be slow because
there could be many object in
On Tue, Jun 24, 2014 at 04:38:41PM +0900, Joonsoo Kim wrote:
> On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
> And, you said that this way of implementation would be slow because
> there could be many object in dead caches and this implementation
> needs node spin_lock on each
On Tue, Jun 24, 2014 at 04:38:41PM +0900, Joonsoo Kim wrote:
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
And, you said that this way of implementation would be slow because
there could be many object in dead caches and this implementation
needs node spin_lock on each
On Tue, Jun 24, 2014 at 04:38:41PM +0900, Joonsoo Kim wrote:
> On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
> > @@ -3462,6 +3474,17 @@ static inline void __cache_free(struct kmem_cache
> > *cachep, void *objp,
> >
> > kmemcheck_slab_free(cachep, objp,
Hi,
On Tue, Jun 24, 2014 at 04:25:54PM +0900, Joonsoo Kim wrote:
> On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
> > @@ -3368,7 +3379,8 @@ static void free_block(struct kmem_cache *cachep,
> > void **objpp, int nr_objects,
> >
> > /* fixup slab chains */
> >
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
> Since a dead memcg cache is destroyed only after the last slab allocated
> to it is freed, we must disable caching of free objects/slabs for such
> caches, otherwise they will be hanging around forever.
>
> For SLAB that means we
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
> Since a dead memcg cache is destroyed only after the last slab allocated
> to it is freed, we must disable caching of free objects/slabs for such
> caches, otherwise they will be hanging around forever.
>
> For SLAB that means we
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
Since a dead memcg cache is destroyed only after the last slab allocated
to it is freed, we must disable caching of free objects/slabs for such
caches, otherwise they will be hanging around forever.
For SLAB that means we must
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
Since a dead memcg cache is destroyed only after the last slab allocated
to it is freed, we must disable caching of free objects/slabs for such
caches, otherwise they will be hanging around forever.
For SLAB that means we must
Hi,
On Tue, Jun 24, 2014 at 04:25:54PM +0900, Joonsoo Kim wrote:
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
@@ -3368,7 +3379,8 @@ static void free_block(struct kmem_cache *cachep,
void **objpp, int nr_objects,
/* fixup slab chains */
if
On Tue, Jun 24, 2014 at 04:38:41PM +0900, Joonsoo Kim wrote:
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
@@ -3462,6 +3474,17 @@ static inline void __cache_free(struct kmem_cache
*cachep, void *objp,
kmemcheck_slab_free(cachep, objp, cachep-object_size);
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
> Since a dead memcg cache is destroyed only after the last slab allocated
> to it is freed, we must disable caching of free objects/slabs for such
> caches, otherwise they will be hanging around forever.
>
> For SLAB that means we
On Fri, Jun 13, 2014 at 12:38:22AM +0400, Vladimir Davydov wrote:
Since a dead memcg cache is destroyed only after the last slab allocated
to it is freed, we must disable caching of free objects/slabs for such
caches, otherwise they will be hanging around forever.
For SLAB that means we must
18 matches
Mail list logo
