From: Alex Shi <seakeel@gmail.com>
To: Chen Wandun <chenwandun@huawei.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: Wed, 18 May 2022 18:29:03 +0800 [thread overview]
Message-ID: <070fe87d-43a0-5e4f-e4c7-c44782c2c195@gmail.com> (raw)
In-Reply-To: <3a31521f-a68a-b2a9-baae-9a458ee17033@huawei.com>
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.
Thanks
Alex
next prev parent reply other threads:[~2022-05-18 10:29 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 [this message]
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
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=070fe87d-43a0-5e4f-e4c7-c44782c2c195@gmail.com \
--to=seakeel@gmail.com \
--cc=alexs@kernel.org \
--cc=chenwandun@huawei.com \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.