linux-kernel - Re: [RFC 0/2] optimise local-tw task resheduling

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]

Message-ID: <ad5d6234-b11d-7ac6-0218-78058df99712@gmail.com>
Date:   Mon, 13 Mar 2023 17:50:28 +0000
From:   Pavel Begunkov <asml.silence@...il.com>
To:     Jens Axboe <axboe@...nel.dk>, io-uring@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/2] optimise local-tw task resheduling

On 3/13/23 14:16, Jens Axboe wrote:
> On 3/12/23 9:45?PM, Pavel Begunkov wrote:
>>>>> Didn't take a closer look just yet, but I grok the concept. One
>>>>> immediate thing I'd want to change is the FACILE part of it. Let's call
>>>>> it something a bit more straightforward, perhaps LIGHT? Or LIGHTWEIGHT?
>>>>
>>>> I don't really care, will change, but let me also ask why?
>>>> They're more or less synonyms, though facile is much less
>>>> popular. Is that your reasoning?
>>
>>> Yep, it's not very common and the name should be self-explanatory
>>> immediately for most people.
>>
>> That's exactly the problem. Someone will think that it's
>> like normal tw but "better" and blindly apply it. Same happened
>> before with priority tw lists.
> 
> But the way to fix that is not through obscure naming, it's through
> better and more frequent review. Naming is hard, but naming should be
> basically self-explanatory in terms of why it differs from not setting
> that flag. LIGHTWEIGHT and friends isn't great either, maybe it should
> just be explicit in that this task_work just posts a CQE and hence it's
> pointless to wake the task to run it unless it'll then meet the criteria
> of having that task exit its wait loop as it now has enough CQEs
> available. IO_UF_TWQ_CQE_POST or something like that. Then if it at some

There are 2 expectations (will add a comment)
1) it's posts no more that 1 CQE, 0 is fine

2) it's not urgent, including that it doesn't lock out scarce
[system wide] resources. DMA mappings come to mind as an example.

IIRC is a problem even now with nvme passthrough and DEFER_TASKRUN

> point gets modified to also encompass different types of task_work that
> should not cause wakes, then it can change again. Just tossing
> suggestions out there...

I honestly don't see how LIGHTWEIGHT is better. I think a proper
name would be _LAZY_WAKE or maybe _DEFERRED_WAKE. It doesn't tell
much about why you would want it, but at least sets expectations
what it does. Only needs a comment that multishot is not supported.

-- 
Pavel Begunkov