linux-kernel - Re: [RFC PATCH v4 00/13] ktask: multithread CPU-intensive kernel work

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: <20181105172931.GP4361@dhcp22.suse.cz>
Date:   Mon, 5 Nov 2018 18:29:31 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Daniel Jordan <daniel.m.jordan@...cle.com>
Cc:     linux-mm@...ck.org, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, aarcange@...hat.com,
        aaron.lu@...el.com, akpm@...ux-foundation.org,
        alex.williamson@...hat.com, bsd@...hat.com,
        darrick.wong@...cle.com, dave.hansen@...ux.intel.com,
        jgg@...lanox.com, jwadams@...gle.com, jiangshanlai@...il.com,
        mike.kravetz@...cle.com, Pavel.Tatashin@...rosoft.com,
        prasad.singamsetty@...cle.com, rdunlap@...radead.org,
        steven.sistare@...cle.com, tim.c.chen@...el.com, tj@...nel.org,
        vbabka@...e.cz
Subject: Re: [RFC PATCH v4 00/13] ktask: multithread CPU-intensive kernel work

On Mon 05-11-18 11:55:45, Daniel Jordan wrote:
> Michal, you mentioned that ktask should be sensitive to CPU utilization[1].
> ktask threads now run at the lowest priority on the system to avoid disturbing
> busy CPUs (more details in patches 4 and 5).  Does this address your concern?
> The plan to address your other comments is explained below.

I have only glanced through the documentation patch and it looks like it
will be much less disruptive than the previous attempts. Now the obvious
question is how does this behave on a moderately or even busy system
when you compare that to a single threaded execution. Some numbers about
best/worst case execution would be really helpful.

I will look closer later.

-- 
Michal Hocko
SUSE Labs