linux-kernel - Re: Question on threaded handlers for managed interrupts

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: <e260dfb0-95c5-778e-2652-f563784cb984@huawei.com>
Date:   Fri, 23 Apr 2021 16:00:47 +0100
From:   John Garry <john.garry@...wei.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Marc Zyngier" <maz@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        "Ingo Molnar" <mingo@...nel.org>
Subject: Re: Question on threaded handlers for managed interrupts

Hi Thomas,

On 23/04/2021 14:01, Thomas Gleixner wrote:
> On Fri, Apr 23 2021 at 12:50, Thomas Gleixner wrote:
>> On Thu, Apr 22 2021 at 17:10, John Garry wrote:
>> OTOH, the way how you splitted the handling into hard/thread context
>> provides already the base for this.
>>
>> The missing piece is infrastructure at the irq/scheduler core level to
>> handle this transparently.
>>
>> I have some horrible ideas how to solve that, but I'm sure the scheduler
>> wizards can come up with a reasonable and generic solution.
> So one thing I forgot to ask is:
> 
> Is the thread simply stuck in the while() loop forever or is
> this just an endless hardirq/thread/hardirq/thread stream?

The thread will process all available completions and then return. I 
added some debug there, and at most we handle maybe max 150-300 
completions per thread run.

So I figure that we have the endless hardirq/thread/hardirq/thread stream.

Thanks,
John