On Tue 18-09-12 18:11:59, Glauber Costa wrote:
> Allow a memcg parameter to be passed during cache creation.
> When the slub allocator is being used, it will only merge
> caches that belong to the same memcg.
>
> Default function is created as a wrapper, passing NULL
> to the memcg version. We
On Tue 18-09-12 18:11:59, Glauber Costa wrote:
Allow a memcg parameter to be passed during cache creation.
When the slub allocator is being used, it will only merge
caches that belong to the same memcg.
Default function is created as a wrapper, passing NULL
to the memcg version. We only
On Mon, 24 Sep 2012, Pekka Enberg wrote:
> So Christoph is proposing that the new caches appear somewhere under
> the cgroups directory and /proc/slabinfo includes aggregated counts,
> right? I'm certainly OK with that.
Caches would appear either in cgroup/slabinfo (which would have the same
On Mon, 24 Sep 2012, Glauber Costa wrote:
> > So Christoph is proposing that the new caches appear somewhere under
> > the cgroups directory and /proc/slabinfo includes aggregated counts,
> > right? I'm certainly OK with that.
> >
> Just for clarification, I am not sure about the aggregate counts
On 09/24/2012 07:38 PM, Pekka Enberg wrote:
> On 09/24/2012 05:56 PM, Christoph Lameter wrote:
>>> On Mon, 24 Sep 2012, Glauber Costa wrote:
>>>
The reason I say it is orthogonal, is that people will still want to see
their caches in /proc/slabinfo, regardless of wherever else they'll
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
>> On Mon, 24 Sep 2012, Glauber Costa wrote:
>>
>>> The reason I say it is orthogonal, is that people will still want to see
>>> their caches in /proc/slabinfo, regardless of wherever else they'll be.
>>> It was a requirement from Pekka in one of
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
> On Mon, 24 Sep 2012, Glauber Costa wrote:
>
>> The reason I say it is orthogonal, is that people will still want to see
>> their caches in /proc/slabinfo, regardless of wherever else they'll be.
>> It was a requirement from Pekka in one of the
On Mon, 24 Sep 2012, Glauber Costa wrote:
> The reason I say it is orthogonal, is that people will still want to see
> their caches in /proc/slabinfo, regardless of wherever else they'll be.
> It was a requirement from Pekka in one of the first times I posted this,
> IIRC.
They want to see total
On 09/24/2012 05:42 PM, Christoph Lameter wrote:
> On Mon, 24 Sep 2012, Glauber Costa wrote:
>
>> But that is orthogonal, isn't it? People will still expect to see it in
>> the old slabinfo file.
>
> The current scheme for memory statistics is
>
> /proc/meminfo contains global counters
>
>
On Mon, 24 Sep 2012, Glauber Costa wrote:
> But that is orthogonal, isn't it? People will still expect to see it in
> the old slabinfo file.
The current scheme for memory statistics is
/proc/meminfo contains global counters
/sys/devices/system/node/nodeX/meminfo
contains node specific
On 09/24/2012 04:41 PM, Christoph wrote:
>
> On Sep 24, 2012, at 3:12, Glauber Costa wrote:
>
>> On 09/21/2012 10:14 PM, Tejun Heo wrote:
>>
>> The new caches will appear under /proc/slabinfo with the rest, with a
>> string appended that identifies the group.
>
> There are f.e. meminfo files
On Sep 24, 2012, at 3:12, Glauber Costa wrote:
> On 09/21/2012 10:14 PM, Tejun Heo wrote:
>
> The new caches will appear under /proc/slabinfo with the rest, with a
> string appended that identifies the group.
There are f.e. meminfo files in the per node directories in sysfs. It would
make
On 09/21/2012 10:14 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
>> +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
>> *cachep)
>> +{
>> +int id = -1;
>> +
>> +if (!memcg)
>> +id =
On 09/21/2012 10:14 PM, Tejun Heo wrote:
Hello, Glauber.
On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
+void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
*cachep)
+{
+int id = -1;
+
+if (!memcg)
+id = ida_simple_get(cache_types,
On Sep 24, 2012, at 3:12, Glauber Costa glom...@parallels.com wrote:
On 09/21/2012 10:14 PM, Tejun Heo wrote:
The new caches will appear under /proc/slabinfo with the rest, with a
string appended that identifies the group.
There are f.e. meminfo files in the per node directories in sysfs.
On 09/24/2012 04:41 PM, Christoph wrote:
On Sep 24, 2012, at 3:12, Glauber Costa glom...@parallels.com wrote:
On 09/21/2012 10:14 PM, Tejun Heo wrote:
The new caches will appear under /proc/slabinfo with the rest, with a
string appended that identifies the group.
There are f.e. meminfo
On Mon, 24 Sep 2012, Glauber Costa wrote:
But that is orthogonal, isn't it? People will still expect to see it in
the old slabinfo file.
The current scheme for memory statistics is
/proc/meminfo contains global counters
/sys/devices/system/node/nodeX/meminfo
contains node specific counters.
On 09/24/2012 05:42 PM, Christoph Lameter wrote:
On Mon, 24 Sep 2012, Glauber Costa wrote:
But that is orthogonal, isn't it? People will still expect to see it in
the old slabinfo file.
The current scheme for memory statistics is
/proc/meminfo contains global counters
On Mon, 24 Sep 2012, Glauber Costa wrote:
The reason I say it is orthogonal, is that people will still want to see
their caches in /proc/slabinfo, regardless of wherever else they'll be.
It was a requirement from Pekka in one of the first times I posted this,
IIRC.
They want to see total
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
On Mon, 24 Sep 2012, Glauber Costa wrote:
The reason I say it is orthogonal, is that people will still want to see
their caches in /proc/slabinfo, regardless of wherever else they'll be.
It was a requirement from Pekka in one of the first
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
On Mon, 24 Sep 2012, Glauber Costa wrote:
The reason I say it is orthogonal, is that people will still want to see
their caches in /proc/slabinfo, regardless of wherever else they'll be.
It was a requirement from Pekka in one of the first times
On 09/24/2012 07:38 PM, Pekka Enberg wrote:
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
On Mon, 24 Sep 2012, Glauber Costa wrote:
The reason I say it is orthogonal, is that people will still want to see
their caches in /proc/slabinfo, regardless of wherever else they'll be.
It was a
On Mon, 24 Sep 2012, Glauber Costa wrote:
So Christoph is proposing that the new caches appear somewhere under
the cgroups directory and /proc/slabinfo includes aggregated counts,
right? I'm certainly OK with that.
Just for clarification, I am not sure about the aggregate counts -
On Mon, 24 Sep 2012, Pekka Enberg wrote:
So Christoph is proposing that the new caches appear somewhere under
the cgroups directory and /proc/slabinfo includes aggregated counts,
right? I'm certainly OK with that.
Caches would appear either in cgroup/slabinfo (which would have the same
format
Hello, Glauber.
On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
> +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
> *cachep)
> +{
> + int id = -1;
> +
> + if (!memcg)
> + id = ida_simple_get(_types, 0, MAX_KMEM_CACHE_TYPES,
> +
Hello, Glauber.
On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
+void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
*cachep)
+{
+ int id = -1;
+
+ if (!memcg)
+ id = ida_simple_get(cache_types, 0, MAX_KMEM_CACHE_TYPES,
+
26 matches
Mail list logo
