linux-kernel - Re: [PATCH v2] Remove __init from padata_do_multithreaded and padata_mt

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] [day] [month] [year] [list]

Message-ID: <20201027212034.qiwk34ihwsdwlqv3@ca-dmjordan1.us.oracle.com>
Date:   Tue, 27 Oct 2020 17:20:34 -0400
From:   Daniel Jordan <daniel.m.jordan@...cle.com>
To:     Nico Pache <npache@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        steffen.klassert@...unet.com, daniel.m.jordan@...cle.com
Subject: Re: [PATCH v2] Remove __init from padata_do_multithreaded and
 padata_mt_helper.

On 10/27/20 12:46 AM, Nico Pache wrote:
> On Wed, Jul 08, 2020 at 03:51:40PM -0400, Daniel Jordan wrote:
> > (I was away for a while)
> > 
> > On Thu, Jul 02, 2020 at 11:55:48AM -0400, Nico Pache wrote:
> > > Allow padata_do_multithreaded function to be called after bootstrap.
> > 
> > The functions are __init because they're currently only needed during boot, and
> > using __init allows the text to be freed once it's over, saving some memory.
> > 
> > So this change, in isolation, doesn't make sense.  If there were an enhancement
> > you were thinking of making, this patch could then be bundled with it so the
> > change is made only when it's used.
> > 
> > However, there's still work that needs to be merged before
> > padata_do_multithreaded can be called after boot.  See the parts about priority
> > adjustments (MAX_NICE/renicing) and concurrency limits in this branch
> > 
> >   https://oss.oracle.com/git/gitweb.cgi?p=linux-dmjordan.git;a=shortlog;h=refs/heads/padata-mt-wip-v0.5
> > 
> > and the ktask discussions from linux-mm/lkml where concerns about these issues
> > were raised.  I plan to post these parts fairly soon and can include you if you
> > want.
>
> I really like the speed benefits I've been able to achieve by using your
> padata multithreaded interface in the branch you linked me to. Do you
> still have plans on moving forward with this upstream?

Yes, I'm still planning to push these patches upstream, but it's going to take
some time with all the prerequisites.  I'm working on remote charging in the
CPU controller now, which is the biggest unfinished task.  A little background
on that here:

https://lore.kernel.org/linux-mm/20200219220859.GF54486@cmpxchg.org/