linux-kernel - Re: [patch 3/3] MM: allow per-cpu vmstat

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:   Thu, 11 May 2017 12:33:29 -0300
From:   Marcelo Tosatti <mtosatti@...hat.com>
To:     Rik van Riel <riel@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Luiz Capitulino <lcapitulino@...hat.com>,
        Linux RT Users <linux-rt-users@...r.kernel.org>
Subject: Re: [patch 3/3] MM: allow per-cpu vmstat_worker configuration

On Wed, May 10, 2017 at 11:34:26AM -0400, Rik van Riel wrote:
> On Wed, 2017-05-03 at 15:40 -0300, Marcelo Tosatti wrote:
> > Following the reasoning on the last patch in the series,
> > this patch allows configuration of the per-CPU vmstat worker:
> > it allows the user to disable the per-CPU vmstat worker.
> > 
> > Signed-off-by: Marcelo Tosatti <mtosatti@...hat.com>
> 
> Is there ever a case where you would want to configure
> this separately from the vmstat_threshold parameter?
> 
> What use cases are you trying to address?

If you have a case where the performance decrease due to lack of vmstat
collection aggretation (vmstat_threshold=1) is significant, so you
increase vmstat_threshold on these CPUs to, say, 10 (and is willing to
accept the cost of outdated vmstatistics by 10).

This is the case that i imagined when separating the options in two
(with the idea to have policy in userspace, not in the kernel).

Do you think such case is not realistic? (Or that there are other
problems by having vmstat_threshold > 1 and vmstat_worker=0).