[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53352B8D.3040402@parallels.com>
Date: Fri, 28 Mar 2014 11:58:05 +0400
From: Vladimir Davydov <vdavydov@...allels.com>
To: Michal Hocko <mhocko@...e.cz>
CC: Greg Thelen <gthelen@...gle.com>, <akpm@...ux-foundation.org>,
<hannes@...xchg.org>, <glommer@...il.com>,
<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
<devel@...nvz.org>, Christoph Lameter <cl@...ux-foundation.org>,
Pekka Enberg <penberg@...nel.org>
Subject: Re: [PATCH -mm 1/4] sl[au]b: do not charge large allocations to memcg
On 03/28/2014 12:43 AM, Michal Hocko wrote:
> On Thu 27-03-14 11:37:11, Vladimir Davydov wrote:
> [...]
>> In fact, do we actually need to charge every random kmem allocation? I
>> guess not. For instance, filesystems often allocate data shared among
>> all the FS users. It's wrong to charge such allocations to a particular
>> memcg, IMO. That said the next step is going to be adding a per kmem
>> cache flag specifying if allocations from this cache should be charged
>> so that accounting will work only for those caches that are marked so
>> explicitly.
>
> How do you select which caches to track?
I though we should pick some objects that are definitely used by most
processes, e.g. mm_struct, task_struct, inodes, dentries, as a first
step, and then add some new objects to the set upon requests.
Now, after Greg's explanation, I admit the idea is rather unjustified,
because charging all objects by default and providing a way to
explicitly exclude some caches from accounting requires much less
efforts and changes to the code.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists