On Fri, Sep 21, 2012 at 11:14:45PM +0300, Pekka Enberg wrote:
> On Fri, Sep 21, 2012 at 11:07 PM, Tejun Heo wrote:
> > Not necessarily disagreeing, but I don't think it's helpful to set the
> > bar impossibly high. Even static_key doesn't have "exactly *zero*"
> > impact. Let's stick to as
On Fri, Sep 21, 2012 at 11:07 PM, Tejun Heo wrote:
> Not necessarily disagreeing, but I don't think it's helpful to set the
> bar impossibly high. Even static_key doesn't have "exactly *zero*"
> impact. Let's stick to as minimal as possible when not in use and
> reasonable in use.
For
Hello,
On Fri, Sep 21, 2012 at 12:41:52PM +0300, Pekka Enberg wrote:
> > I am already using static keys extensively in this patchset, and that is
> > how I intend to handle this particular case.
>
> Cool.
>
> The key point here is that !CONFIG_MEMCG_KMEM should have exactly *zero*
>
On Fri, 21 Sep 2012, Glauber Costa wrote:
> > We should assume that most distributions enable CONFIG_MEMCG_KMEM,
> > right? Therfore, any performance impact should be dependent on whether
> > or not kmem memcg is *enabled* at runtime or not.
> >
> > Can we use the "static key" thingy introduced
On 09/21/2012 01:33 PM, Pekka Enberg wrote:
> On Wed, Sep 19, 2012 at 10:42 AM, Glauber Costa wrote:
index f2d760c..18de3f6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
* Free an object which was previously allocated from this
On Wed, Sep 19, 2012 at 10:42 AM, Glauber Costa wrote:
>>> index f2d760c..18de3f6 100644
>>> --- a/mm/slab.c
>>> +++ b/mm/slab.c
>>> @@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
>>> * Free an object which was previously allocated from this
>>> * cache.
>>> */
>>> -void
On Wed, Sep 19, 2012 at 10:42 AM, Glauber Costa glom...@parallels.com wrote:
index f2d760c..18de3f6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
* Free an object which was previously allocated from this
* cache.
*/
-void
On 09/21/2012 01:33 PM, Pekka Enberg wrote:
On Wed, Sep 19, 2012 at 10:42 AM, Glauber Costa glom...@parallels.com wrote:
index f2d760c..18de3f6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
* Free an object which was previously allocated from this
On Fri, 21 Sep 2012, Glauber Costa wrote:
We should assume that most distributions enable CONFIG_MEMCG_KMEM,
right? Therfore, any performance impact should be dependent on whether
or not kmem memcg is *enabled* at runtime or not.
Can we use the static key thingy introduced by tracing
Hello,
On Fri, Sep 21, 2012 at 12:41:52PM +0300, Pekka Enberg wrote:
I am already using static keys extensively in this patchset, and that is
how I intend to handle this particular case.
Cool.
The key point here is that !CONFIG_MEMCG_KMEM should have exactly *zero*
performance impact
On Fri, Sep 21, 2012 at 11:07 PM, Tejun Heo t...@kernel.org wrote:
Not necessarily disagreeing, but I don't think it's helpful to set the
bar impossibly high. Even static_key doesn't have exactly *zero*
impact. Let's stick to as minimal as possible when not in use and
reasonable in use.
For
On Fri, Sep 21, 2012 at 11:14:45PM +0300, Pekka Enberg wrote:
On Fri, Sep 21, 2012 at 11:07 PM, Tejun Heo t...@kernel.org wrote:
Not necessarily disagreeing, but I don't think it's helpful to set the
bar impossibly high. Even static_key doesn't have exactly *zero*
impact. Let's stick to
On Wed, 19 Sep 2012, Glauber Costa wrote:
> > This is an extremely hot path of the kernel and you are adding significant
> > processing. Check how the benchmarks are influenced by this change.
> > virt_to_cache can be a bit expensive.
> Would it be enough for you to have a separate code path for
On 09/18/2012 07:28 PM, Christoph Lameter wrote:
> On Tue, 18 Sep 2012, Glauber Costa wrote:
>
>> index f2d760c..18de3f6 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
>> * Free an object which was previously allocated from this
>> * cache.
>>
On 09/18/2012 07:28 PM, Christoph Lameter wrote:
On Tue, 18 Sep 2012, Glauber Costa wrote:
index f2d760c..18de3f6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
* Free an object which was previously allocated from this
* cache.
*/
-void
On Wed, 19 Sep 2012, Glauber Costa wrote:
This is an extremely hot path of the kernel and you are adding significant
processing. Check how the benchmarks are influenced by this change.
virt_to_cache can be a bit expensive.
Would it be enough for you to have a separate code path for
On Tue, 18 Sep 2012, Glauber Costa wrote:
> index f2d760c..18de3f6 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
> * Free an object which was previously allocated from this
> * cache.
> */
> -void kmem_cache_free(struct kmem_cache *cachep,
struct page already have this information. If we start chaining
caches, this information will always be more trustworthy than
whatever is passed into the function
A parent pointer is added to the slub structure, so we can make sure
the freeing comes from either the right slab, or from its
struct page already have this information. If we start chaining
caches, this information will always be more trustworthy than
whatever is passed into the function
A parent pointer is added to the slub structure, so we can make sure
the freeing comes from either the right slab, or from its
On Tue, 18 Sep 2012, Glauber Costa wrote:
index f2d760c..18de3f6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
* Free an object which was previously allocated from this
* cache.
*/
-void kmem_cache_free(struct kmem_cache *cachep, void *objp)
20 matches
Mail list logo
