On Mon, Jun 02, 2014 at 10:24:09AM -0500, Christoph Lameter wrote:
> On Sat, 31 May 2014, Vladimir Davydov wrote:
>
> > > You can use a similar approach than in SLUB. Reduce the size of the per
> > > cpu array objects to zero. Then SLAB will always fall back to its slow
> > > path in
On Mon, Jun 02, 2014 at 11:01:55PM +0900, Joonsoo Kim wrote:
> 2014-06-02 21:10 GMT+09:00 Vladimir Davydov :
> > On Mon, Jun 02, 2014 at 01:41:55PM +0900, Joonsoo Kim wrote:
> >> According to my code reading, slabs_to_free() doesn't return number of
> >> free slabs. This bug is introduced by
On Mon, Jun 02, 2014 at 11:01:55PM +0900, Joonsoo Kim wrote:
2014-06-02 21:10 GMT+09:00 Vladimir Davydov vdavy...@parallels.com:
On Mon, Jun 02, 2014 at 01:41:55PM +0900, Joonsoo Kim wrote:
According to my code reading, slabs_to_free() doesn't return number of
free slabs. This bug is
On Mon, Jun 02, 2014 at 10:24:09AM -0500, Christoph Lameter wrote:
On Sat, 31 May 2014, Vladimir Davydov wrote:
You can use a similar approach than in SLUB. Reduce the size of the per
cpu array objects to zero. Then SLAB will always fall back to its slow
path in cache_flusharray()
On Sat, 31 May 2014, Vladimir Davydov wrote:
> > You can use a similar approach than in SLUB. Reduce the size of the per
> > cpu array objects to zero. Then SLAB will always fall back to its slow
> > path in cache_flusharray() where you may be able to do something with less
> > of an impact on
2014-06-02 21:10 GMT+09:00 Vladimir Davydov :
> On Mon, Jun 02, 2014 at 01:41:55PM +0900, Joonsoo Kim wrote:
>> According to my code reading, slabs_to_free() doesn't return number of
>> free slabs. This bug is introduced by 0fa8103b. I think that it is
>> better to fix it before applyting this
On Mon, Jun 02, 2014 at 01:41:55PM +0900, Joonsoo Kim wrote:
> According to my code reading, slabs_to_free() doesn't return number of
> free slabs. This bug is introduced by 0fa8103b. I think that it is
> better to fix it before applyting this patch. Otherwise, use n->free_objects
> instead of
On Mon, Jun 02, 2014 at 01:41:55PM +0900, Joonsoo Kim wrote:
According to my code reading, slabs_to_free() doesn't return number of
free slabs. This bug is introduced by 0fa8103b. I think that it is
better to fix it before applyting this patch. Otherwise, use n-free_objects
instead of
2014-06-02 21:10 GMT+09:00 Vladimir Davydov vdavy...@parallels.com:
On Mon, Jun 02, 2014 at 01:41:55PM +0900, Joonsoo Kim wrote:
According to my code reading, slabs_to_free() doesn't return number of
free slabs. This bug is introduced by 0fa8103b. I think that it is
better to fix it before
On Sat, 31 May 2014, Vladimir Davydov wrote:
You can use a similar approach than in SLUB. Reduce the size of the per
cpu array objects to zero. Then SLAB will always fall back to its slow
path in cache_flusharray() where you may be able to do something with less
of an impact on
On Fri, May 30, 2014 at 05:51:11PM +0400, Vladimir Davydov wrote:
> There is no use in keeping free objects/slabs on dead memcg caches,
> because they will never be allocated. So let's make cache_reap() shrink
> as many free objects from such caches as possible.
>
> Note the difference between
On Fri, May 30, 2014 at 05:51:11PM +0400, Vladimir Davydov wrote:
There is no use in keeping free objects/slabs on dead memcg caches,
because they will never be allocated. So let's make cache_reap() shrink
as many free objects from such caches as possible.
Note the difference between SLAB
On Fri, May 30, 2014 at 10:01:26AM -0500, Christoph Lameter wrote:
> On Fri, 30 May 2014, Vladimir Davydov wrote:
>
> > We don't disable free objects caching for SLAB, because it would force
> > kfree to always take a spin lock, which would degrade performance
> > significantly.
>
> You can use
On Fri, May 30, 2014 at 10:01:26AM -0500, Christoph Lameter wrote:
On Fri, 30 May 2014, Vladimir Davydov wrote:
We don't disable free objects caching for SLAB, because it would force
kfree to always take a spin lock, which would degrade performance
significantly.
You can use a similar
On Fri, 30 May 2014, Vladimir Davydov wrote:
> There is no use in keeping free objects/slabs on dead memcg caches,
> because they will never be allocated. So let's make cache_reap() shrink
> as many free objects from such caches as possible.
>
> Note the difference between SLAB and SLUB handling
There is no use in keeping free objects/slabs on dead memcg caches,
because they will never be allocated. So let's make cache_reap() shrink
as many free objects from such caches as possible.
Note the difference between SLAB and SLUB handling of dead memcg caches.
For SLUB, dead cache destruction
There is no use in keeping free objects/slabs on dead memcg caches,
because they will never be allocated. So let's make cache_reap() shrink
as many free objects from such caches as possible.
Note the difference between SLAB and SLUB handling of dead memcg caches.
For SLUB, dead cache destruction
On Fri, 30 May 2014, Vladimir Davydov wrote:
There is no use in keeping free objects/slabs on dead memcg caches,
because they will never be allocated. So let's make cache_reap() shrink
as many free objects from such caches as possible.
Note the difference between SLAB and SLUB handling of
18 matches
Mail list logo
