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: <54EB82D0.9080606@redhat.com>
Date:	Mon, 23 Feb 2015 14:43:12 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Ebru Akagunduz <ebru.akagunduz@...il.com>, linux-mm@...ck.org,
	kirill@...temov.name, mhocko@...e.cz, mgorman@...e.de,
	rientjes@...gle.com, sasha.levin@...cle.com, hughd@...gle.com,
	hannes@...xchg.org, vbabka@...e.cz, linux-kernel@...r.kernel.org,
	aarcange@...hat.com, keithr@...m.mit.edu, dvyukov@...gle.com
Subject: Re: [PATCH v2] mm: incorporate zero pages into transparent huge pages

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/23/2015 02:16 PM, Andrew Morton wrote:
> On Wed, 18 Feb 2015 19:08:12 -0500 Rik van Riel <riel@...hat.com>
> wrote:

>>> If so, this might be rather undesirable behaviour in some 
>>> situations (and ditto the current behaviour for pte_none
>>> ptes)?
>>> 
>>> This can be tuned by adjusting khugepaged_max_ptes_none,

> Here's a live one:
> https://bugzilla.kernel.org/show_bug.cgi?id=93111
> 
> Application does MADV_DONTNEED to free up a load of memory and
> then khugepaged comes along and pages that memory back in again.
> It seems a bit silly to do this after userspace has deliberately
> discarded those pages!
> 
> Presumably MADV_NOHUGEPAGE can be used to prevent this, but it's a
> bit of a hand-grenade.  I guess the MADV_DONTNEED manpage should be
> updated to explain all this?

That makes me wonder what a good value for khugepaged_max_ptes_none
would be.

Doubling the amount of memory a program uses seems quite unreasonable.

Increasing the amount of memory a program uses by 512x seems totally
unreasonable.

Increasing the amount of memory a program uses by 20% might be
reasonable, if that much memory is available, since that seems to
be about how much performance improvement we have ever seen from
THP.

Andrew, Andrea, do you have any ideas on this?

Is this something to just set, or should we ask Ebru to run
a few different tests with this?

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU64LQAAoJEM553pKExN6DbjAH/31KsggMczFT5Z6KQ68dnMnc
nlYAHmiC8nBzguhj5fUtm94jWBK1IPg9cUkRt1tKDJXkVGk91it0MdO1QhuSL91b
xNghqc1d8/P/dmuguNH6C7BUlf52iFFyaCrnip+sO1rxIEUYkFwHxpwC5vSlLrrl
bENlILFuY5kmF2xd6kIfvhOr7TzkbCS92Da3la0sCIT4tjlXPKJ6fuTo9aK8LOqr
kKi6gmmyH+gDhi2EAJk3D1cZT8RqrynsbirEEcWq+ORNUScmSqNlQqGOLw/nJeSp
Nkw7rReeMz5PHVxnsNQE4kxQ4zIJ0auZsZ9cC4Gw3ZpQKdiLBiAK+lJECgQsqPk=
=pDxP
-----END PGP SIGNATURE-----
--
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