linux-kernel - Re: [PATCH] mm, compaction: Indicate when compaction is manually triggered by sysctl

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 May 2020 09:06:14 +0200
From:   peter enderborg <peter.enderborg@...y.com>
To:     Guilherme Piccoli <gpiccoli@...onical.com>,
        David Rientjes <rientjes@...gle.com>
CC:     "Guilherme G. Piccoli" <kernel@...ccoli.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        Gavin Guo <gavin.guo@...onical.com>,
        Mel Gorman <mgorman@...hsingularity.net>
Subject: Re: [PATCH] mm, compaction: Indicate when compaction is manually
 triggered by sysctl

On 5/11/20 1:26 PM, Guilherme Piccoli wrote:
> On Sun, May 10, 2020 at 10:25 PM David Rientjes <rientjes@...gle.com> wrote:
>> [...]
>> The kernel log is not preferred for this (or drop_caches, really) because
>> the amount of info can causing important information to be lost.  We don't
>> really gain anything by printing that someone manually triggered
>> compaction; they could just write to the kernel log themselves if they
>> really wanted to.  The reverse is not true: we can't suppress your kernel
>> message with this patch.
>>
>> Instead, a statsfs-like approach could be used to indicate when this has
>> happened and there is no chance of losing events because it got scrolled
>> off the kernel log.  It has the added benefit of not requiring the entire
>> log to be parsed for such events.
> OK, agreed! Let's forget the kernel log. So, do you think the way to
> go is the statsfs, not a zoneinfo stat, a per-node thing? I'm saying
> that because kernel mm subsystem statistics seem pretty.."comfortable"
> the way they are, in files like vmstat, zoneinfo, etc. Let me know
> your thoughts on this, if I could work on that or should wait statsfs.
> Thanks,
>
>
> Guilherme

I think a trace notification in compaction like kcompad_wake would be good.