linux-kernel - Re: [GIT PULL] Lockless SLUB slowpaths for v3.1-rc1

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20110801092205.14881df1.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Mon, 1 Aug 2011 09:22:05 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>, cl@...ux-foundation.org,
	akpm@...ux-foundation.org, rientjes@...gle.com, hughd@...gle.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	kosaki.motohiro@...fujitsu.com, yinghan@...gle.com
Subject: Re: [GIT PULL] Lockless SLUB slowpaths for v3.1-rc1

On Sun, 31 Jul 2011 10:39:58 -0700
Andi Kleen <andi@...stfloor.org> wrote:

> Linus Torvalds <torvalds@...ux-foundation.org> writes:
> 
> > On Sat, Jul 30, 2011 at 8:27 AM, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> >>
> >> Do we allocate the page map array sufficiently aligned that we
> >> actually don't ever have the case of straddling a cacheline? I didn't
> >> check.
> >
> > Oh, and another thing worth checking: did somebody actually check the
> > timings for:
> 
> I would like to see a followon patch that moves the mem_cgroup
> pointer back into struct page. Copying some mem_cgroup people.
> 

A very big change itself is in a future plan. It will do memory usage of
page_cgroup from 32bytes to 8bytes.

A small change, moving page_cgroup->mem_cgroup to struct page, may make
sense. But...IIUC, there is an another user of a field as blkio cgroup.
(They planned to add page_cgroup->blkio_cgroup)

So, my idea is adding

	page->owner

field and encode it in some way. For example, if we can encode it as

	|owner_flags | blkio_id | | memcg_id|

this will work. (I'm not sure how performance will be..)
And we can reduce size of page_cgroup from 32->24(or 16).

In this usage, page->owner will be just required when CGROUP is used.
So, a small machine will not need to increase size of struct page.

If you increase size of 'struct page', memcg will try to make use of
the field.

But we have now some pending big patches (dirty_ratio etc...), moving
pointer may take longer than expected. 

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/