linux-kernel - Re: [PATCH] Move memory controller allocations to their own slabs (v3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080314115645.e78b7f5c.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Fri, 14 Mar 2008 11:56:45 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Balbir Singh <balbir@...ux.vnet.ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelianov <xemul@...nvz.org>,
	Hugh Dickins <hugh@...itas.com>,
	Sudhir Kumar <skumar@...ux.vnet.ibm.com>,
	YAMAMOTO Takashi <yamamoto@...inux.co.jp>,
	Paul Menage <menage@...gle.com>, lizf@...fujitsu.com,
	linux-kernel@...r.kernel.org, taka@...inux.co.jp,
	linux-mm@...ck.org, David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH] Move memory controller allocations to their own slabs
 (v3)

On Thu, 13 Mar 2008 19:33:07 +0530
Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:

> 
> 
> Changelog v3
> 
> 1. Remove HWCACHE_ALIGN
> 
> Changelog v2
> 
> 1. Remove extra slab for mem_cgroup_per_zone
> 
> Move the memory controller data structure page_cgroup to its own slab cache.
> It saves space on the system, allocations are not necessarily pushed to order
> of 2 and should provide performance benefits. Users who disable the memory
> controller can also double check that the memory controller is not allocating
> page_cgroup's.
> 
> NOTE: Hugh Dickins brought up the issue of whether we want to mark page_cgroup
> as __GFP_MOVABLE or __GFP_RECLAIMABLE. I don't think there is an easy
> answer at the moment. page_cgroup's are associated with user pages,
> they can be reclaimed once the user page has been reclaimed, so it might
> make sense to mark them as __GFP_RECLAIMABLE. For now, I am leaving the
> marking to default values that the slab allocator uses.
> 
> Comments?
> 
At first, in my understanding,
- MOVABLE is for migratable pages. (so, not for kernel objects.)
- RECLAIMABLE is for reclaimable kernel objects. (for slab etc..)

All reclaimable objects are not necessary to be always reclaimable but
some amount of RECLAIMABLE objects (not all) should be recraimable easily.
For example, some of dentry-cache, inode-cache is reclaimable because *unused*
objects are cached.

When it comes to page_cgroup, *all* objects has dependency to pages which are
assigned to.  And user pages are reclaimable.
There is a similar object....the radix tree. radix-tree's node is allocated as
RECLAIMABLE object.

So I think it makes sense to changing page_cgroup to be reclaimable.

But final decision should be done by how fragmentation avoidance works.
It's good to test "how many hugepages can be allocated dynamically" when we
make page_cgroup to be GFP_RECAIMABLE 

Thanks,
-Kame


--
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/