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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/13/23 11:50?AM, Pavel Begunkov wrote:
> 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

DMA mappings aren't really scarce, only on weird/crappy setups with a
very limited IOMMU space where and IOMMU is being used. So not a huge
deal I think.

>> 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.

Agree, and this is what I said too, LIGHTWEIGHT isn't a great word
either. DEFERRED_WAKE seems like a good candidate, and it'd be great to
also include a code comment there on what it does. That'll help future
contributors.

-- 
Jens Axboe




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux