linux-kernel - Re: [PATCH 1/2] psi: add support for multi level pressure stall trigger

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]

Date:   Thu, 19 May 2022 11:34:36 -0700
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     Alex Shi <seakeel@...il.com>
Cc:     Chen Wandun <chenwandun@...wei.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Alex Shi <alexs@...nel.org>, Jonathan Corbet <corbet@....net>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 1/2] psi: add support for multi level pressure stall trigger

On Wed, May 18, 2022 at 11:15 PM Alex Shi <seakeel@...il.com> wrote:
>
>
>
> On 5/19/22 05:38, Suren Baghdasaryan wrote:
> > On Wed, May 18, 2022 at 3:29 AM Alex Shi <seakeel@...il.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. :)
> BTW, I still don't see the strong reason for the pressure range.
>
> > > 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?

Ok, sounds like userspace can handle the situation of multiple
triggers firing. Let's keep it simple as it is now, until we see a
strong need or convincing performance numbers for adding this new
trigger attribute.
Chen, if you can provide reasons why a userspace solution would be
prohibitive I would be happy to reconsider.
Thanks,
Suren.

>
> Thanks
> Alex