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: <20090803211112.CC23.A69D9226@jp.fujitsu.com>
Date:	Mon,  3 Aug 2009 21:12:53 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	kosaki.motohiro@...fujitsu.com,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Paul Menage <menage@...gle.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch -mm v2] mm: introduce oom_adj_child


One mistake.

> > > And, May I explay why I think your oom_adj_child is wrong idea?
> > > The fact is: new feature introducing never fix regression. yes, some
> > > application use new interface and disappear the problem. but other
> > > application still hit the problem. that's not correct development style
> > > in kernel.
> > > 
> > 
> > So you're proposing that we forever allow /proc/pid/oom_score to be 
> > completely wrong for pid without any knowledge to userspace?  That we 
> > falsely advertise what it represents and allow userspace to believe that 
> > changing oom_adj for a thread sharing memory with other threads actually 
> > changes how the oom killer selects tasks?
> 
> No. perhaps no doublly.
> 
> 1) In my patch, oom_score is also per-process value. all thread have the same
>    oom_score.
>    It's clear meaning.

it's wrong explanation. oom_score is calculated from the same oom_adj.
but it have each different oom_score. sorry my confused.



> 2) In almost case, oom_score display collect value because oom_adj is per-process
>    value too. 
>    Yes, there is one exception. vfork() and change oom_adj'ed process might display 
>    wrong value. but I don't think it is serious problem because vfork() process call
>    exec() soon.
>    Administrator never recognize this difference.
> 
> > Please.
> 
> David, I hope you join to fix this regression. I can't believe we
> can't fix this issue honestly.
> 
> 
> 



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

Powered by Openwall GNU/*/Linux Powered by OpenVZ