linux-kernel - Re: [PATCH] mm: Move readahead limit outside of readahead, and advisory syscalls

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: <CAEPKNTJjqcmap70nEaVVixK9486mp=-MKuDBCCdHdP4cx-D2Yw@mail.gmail.com>
Date:	Tue, 26 Jul 2016 15:23:42 -0400
From:	Kyle Walker <kwalker@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Michal Hocko <mhocko@...e.com>,
	Geliang Tang <geliangtang@....com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Roman Gushchin <klamm@...dex-team.ru>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] mm: Move readahead limit outside of readahead, and
 advisory syscalls

On Mon, Jul 25, 2016 at 4:47 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
>
> Can this suffering be quantified please?
>

The observed suffering is primarily visible within an IBM Qradar
installation. From a high level, the lower limit to the amount of advisory
readahead pages results in a 3-5x increase in time necessary to complete
an identical query within the application.

Note, all of the below values are with Readahead configured to 64Kib.

Baseline behaviour - Prior to:
 600e19af ("mm: use only per-device readahead limit")
 6d2be915 ("mm/readahead.c: fix readahead failure for memoryless NUMA
           nodes and limit readahead pages")

Result:
 Qradar - Command: "username equals root" - 57.3s to complete search

New performance - With:
 600e19af ("mm: use only per-device readahead limit")
 6d2be915 ("mm/readahead.c: fix readahead failure for memoryless NUMA
           nodes and limit readahead pages")

Result:
 Qradar - "username equals root" query - 245.7s to complete search

Proposed behaviour - With the proposed patch in place.

Result:
 Qradar - "username equals root" query - 57s to complete search

In narrowing the source of the performance deficit, it was observed that
the amount of data loaded into pagecache via madvise was quite a bit lower
following the noted commits. As simply reverting those lower limits were
not accepted previously, the proposed alternative strategy seemed like the
most beneficial path forwards.

>
> Linus probably has opinions ;)
>

I understand that changes to readahead that are very similar have been
proposed quite a bit lately. If there are any changes or testing needed,
I'm more than happy to tackle that.

Thank you in advance!
-- 
Kyle Walker