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  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]
Date:	Sat, 05 Jul 2008 12:19:11 +0530
From:	Balbir Singh <>
To:	KAMEZAWA Hiroyuki <>
CC:	Andrew Morton <>,,,
	"" <>,
	"" <>,
	"" <>
Subject: Re: [PATCH] memcg: handle shmem's swap cache (Was 2.6.26-rc8-mm1

KAMEZAWA Hiroyuki wrote:
> On Sat, 05 Jul 2008 11:11:10 +0530
> Balbir Singh <> wrote:
>> KAMEZAWA Hiroyuki wrote:
>>> My swapcache accounting under memcg patch failed to catch tmpfs(shmem)'s one.
>>> Can I test this under -mm tree ?
>>> (If -mm is busy, I'm not in hurry.)
>>> This patch works well in my box.
>>> =
>>> SwapCache handling fix.
>>> shmem's swapcache behavior is a little different from anonymous's one and
>>> memcg failed to handle it. This patch tries to fix it.
>>> After this:
>>> Any page marked as SwapCache is not uncharged. (delelte_from_swap_cache()
>>> delete the SwapCache flag.)
>>> To check a shmem-page-cache is alive or not we use
>>>  page->mapping && !PageAnon(page) instead of
>>>  pc->flags & PAGE_CGROUP_FLAG_CACHE.
>>> Signed-off-by: KAMEZAWA Hiroyuki <>
>> Though I am not opposed to this, I do sit up and think if keeping the reference
>> count around could avoid this complexity and from my point, the maintenance
>> overhead of this logic/code (I fear there might be more special cases :( )
> yes, to me. but we have to fix..
> But I don't like old code's refcnt handling which does
>    - increment
>      - does this increment was really neccesary ?
>        No? ok, decrement it again.
> This was much more complex to me than current code.

That can be redone -- the moment a page is used by a path, refcnt (increment)
it. Undo the same when the page is no longer in use.

I expect

rmap path to increment/decrement it on mapping
radix-tree (cache's) to do the same

Using a kref we should be able to get this logic right - no?

> And old ones will needs the check at treating swap-cache. (it couldn't but if we want)
>> The trade-off is complexity versus the overhead of reference counting.
> refcnt was also very complex ;)

I think that is easier to simply, instead of adding the complex checks we have
right now. refcnt is easier to prove as working correct than the checks.

	Warm Regards,
	Balbir Singh
	Linux Technology Center
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists