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: <20080212145651.69cc34a5.akpm@linux-foundation.org>
Date:	Tue, 12 Feb 2008 14:56:51 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	kosaki.motohiro@...fujitsu.com, marcelo@...ck.org,
	daniel.spang@...il.com, riel@...hat.com, alan@...rguk.ukuu.org.uk,
	linux-fsdevel@...r.kernel.org, pavel@....cz, a1426z@...ab.com,
	jonathan@...masters.org, zlynx@....org
Subject: Re: [PATCH 4/8][for -mm] mem_notify v6: memory_pressure_notify()
 caller

On Sun, 10 Feb 2008 00:24:28 +0900
"KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com> wrote:

> the notification point to happen whenever the VM moves an
> anonymous page to the inactive list - this is a pretty good indication
> that there are unused anonymous pages present which will be very likely
> swapped out soon.
> 
> and, It is judged out of trouble at the fllowing situations.
>  o memory pressure decrease and stop moves an anonymous page to the
> inactive list.
>  o free pages increase than (pages_high+lowmem_reserve)*2.

This seems rather arbitrary.  Why choose this stage in the page
reclaimation process rather than some other stage?

If this feature is useful then I'd expect that some applications would want
notification at different times, or at different levels of VM distress.  So
this semi-randomly-chosen notification point just won't be strong enough in
real-world use.

Does this change work correctly and appropriately for processes which are
running in a cgroup memory controller?

Given the amount of code which these patches add, and the subsequent
maintenance burden, and the unlikelihood of getting many applications to
actually _use_ the interface, it is not obvious to me that inclusion in the
kernel is justifiable, sorry.


memory_pressure_notify() is far too large to be inlined.

Some of the patches were wordwrapped.


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