From: Chen Wandun <chenwandun@huawei.com>
To: Alex Shi <seakeel@gmail.com>, Suren Baghdasaryan <surenb@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>, Alex Shi <alexs@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 1/2] psi: add support for multi level pressure stall trigger
Date: Sat, 21 May 2022 15:23:01 +0800 [thread overview]
Message-ID: <9fc88a71-b484-c471-66cd-a4d87d8c02c4@huawei.com> (raw)
In-Reply-To: <29d66a46-d141-2d02-45dd-a8931786588e@gmail.com>
在 2022/5/19 14:15, Alex Shi 写道:
>
> On 5/19/22 05:38, Suren Baghdasaryan wrote:
>> On Wed, May 18, 2022 at 3:29 AM Alex Shi <seakeel@gmail.com> wrote:
>>>
>>>
>>> On 5/17/22 20:46, Chen Wandun wrote:
>>>>>>> This breaks the old ABI. And why you need this new function?
>>>>>> Both great points.
>>>>> BTW, I think the additional max_threshold parameter could be
>>>>> implemented in a backward compatible way so that the old API is not
>>>>> broken:
>>>>>
>>>>> arg_count = sscanf(buf, "some %u %u %u", &min_threshold_us, &arg2, &arg3);
>>>>> if (arg_count < 2) return ERR_PTR(-EINVAL);
>>>>> if (arg_count < 3) {
>>>>> max_threshold_us = INT_MAX;
>>>>> window_us = arg2;
>>>>> } else {
>>>>> max_threshold_us = arg2;
>>>>> window_us = arg3;
>>>>> }
>>>> OK
>>>>
>>>> Thanks.
>>>>> But again, the motivation still needs to be explained.
>>>> we want do different operation for different stall level,
>>>> just as prev email explain, multi trigger is also OK in old
>>>> ways, but it is a litter complex.
>>> In fact, I am not keen for this solution, the older and newer
>>> interface is easy to be confused by users, for some resolvable
>>> unclear issues. It's not a good idea.
>> Maybe adding the max_threshold as an optional last argument will be
>> less confusing? Smth like this:
>>
>> some/full min_threshold window_size [max_threshold]
> It's already confused enough. :)
which point make you confused?
Interface suggest by Suren is compatible with current version,
I think it is more reasonable and there is no difficuty to understand it.
> BTW, I still don't see the strong reason for the pressure range.
Considering this case:
I divide pressure into multi levels, and each level corresponds to a
hander, I have to register multi triggers and wait for fire events,
nowadays, these trigger is something like:
echo “some 150000 1000000” > /proc/pressure/memory
echo “some 350000 1000000” > /proc/pressure/memory
echo “some 550000 1000000” > /proc/pressure/memory
echo “some 750000 1000000” > /proc/pressure/memory
In the best case, stall pressure between 150000 and 350000,
only one trigger fire, and only one wakeup.
In any other case, multi triggers fire and multi wakeup, but it
indeed is no need.
New implement make the fire and wakeup more precise,
userspace code will be more simple, no confusing fire event,
no need to filter fire event anymore, maybe minor performance
improved.
Thanks.
>
>>> Also, if we do decide to add it, there should be a warning in the
>> documentation that max_threshold usage might lead to a stall being
>> missed completely. In your example:
>>
>> echo "some 150000 350000 1000000" > /proc/pressure/memory
>>
>> If there is a stall of more than 350ms within a given window, that
>> trigger will not fire at all.
> Right.
> And what if others propose more pressure combinations?
> Maybe leave them to user space is more likely workable?
>
> Thanks
> Alex
> .
next prev parent reply other threads:[~2022-05-21 7:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 3:35 [PATCH 1/2] psi: add support for multi level pressure stall trigger Chen Wandun
2022-05-16 3:35 ` [PATCH 2/2] psi: add description about multi level pressure trigger Chen Wandun
2022-05-16 6:20 ` [PATCH 1/2] psi: add support for multi level pressure stall trigger Alex Shi
2022-05-16 8:21 ` Suren Baghdasaryan
2022-05-16 8:43 ` Suren Baghdasaryan
2022-05-17 12:46 ` Chen Wandun
2022-05-17 17:35 ` Suren Baghdasaryan
2022-05-18 9:55 ` Chen Wandun
2022-05-18 10:29 ` Alex Shi
2022-05-18 21:38 ` Suren Baghdasaryan
2022-05-19 6:15 ` Alex Shi
2022-05-19 18:34 ` Suren Baghdasaryan
2022-05-21 7:23 ` Chen Wandun [this message]
2022-05-21 10:13 ` Alex Shi
2022-05-21 10:34 ` Chen Wandun
2022-05-17 9:38 ` Chen Wandun
2022-05-17 9:08 ` Chen Wandun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fc88a71-b484-c471-66cd-a4d87d8c02c4@huawei.com \
--to=chenwandun@huawei.com \
--cc=alexs@kernel.org \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seakeel@gmail.com \
--cc=surenb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox