linux-kernel - Re: [RFC] Shared page accounting for memory cgroup

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]

Date:	Mon, 18 Jan 2010 09:22:17 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>
Subject: Re: [RFC] Shared page accounting for memory cgroup

On Mon, 18 Jan 2010 09:05:49 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:

> > 
> > Kamezawa-San,
> > 
> > I implemented the same in user space and I get really bad results, here is why
> > 
> > 1. I need to hold and walk the tasks list in cgroups and extract RSS
> > through /proc (results in worse hold times for the fork() scenario you
> > menioned)
> > 2. The data is highly inconsistent due to the higher margin of error
> > in accumulating data which is changing as we run. By the time we total
> > and look at the memcg data, the data is stale
> > 
> > Would you be OK with the patch, if I renamed "shared_usage_in_bytes"
> > to "non_private_usage_in_bytes"?
> > 
> > Given that the stat is user initiated, I don't see your concern w.r.t.
> > overhead. Many subsystems like KSM do pay the overhead cost if the
> > user really wants the feature or the data. I would be really
> > interested in other opinions as well (if people do feel strongly
> > against or for the feature)
> > 
> 
> Please add that featuter to global VM before memcg.
> If VM guyes admits its good, I have no objections more.
> 

I don't want to say any more but...one point.

If the status of memory changes so frequently as the user land check program
can't calculate stable data, what the management daemon can react agasinst
it...the stale data ? So, I think it's nonsense anyway.

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/