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:   Tue, 18 Dec 2018 08:41:26 -0800
From:   Tejun Heo <tj@...nel.org>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     Angelo Ruocco <angelo.ruocco.90@...il.com>,
        'Paolo Valente' via bfq-iosched 
        <bfq-iosched@...glegroups.com>, Jens Axboe <axboe@...nel.dk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Li Zefan <lizefan@...wei.com>,
        Angelo Ruocco <angeloruocco90@...il.com>,
        Dennis Zhou <dennis@...nel.org>,
        Josef Bacik <josef@...icpanda.com>,
        Liu Bo <bo.liu@...ux.alibaba.com>,
        Bart Van Assche <bvanassche@....org>,
        Johannes Weiner <hannes@...xchg.org>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        ulf.hansson@...aro.org, linus.walleij@...aro.org,
        broonie@...nel.org, oleksandr@...alenko.name,
        cgroups@...r.kernel.org, linux-doc@...r.kernel.org,
        Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH V2 00/10] unify the interface of the proportional-share
 policy in blkio/io

Hello, Paolo.

On Tue, Dec 18, 2018 at 08:48:10AM +0100, Paolo Valente wrote:
> If Tejun cannot see any solution to his concern, then can we just
> switch to this extension, considering that
> - for non-shared names the interface is *identical* to the current
>   one;
> - by using this new interface, and getting feedback we could
>   understand how to better handle Tejun's concern?
> A lot of systems do use weights, and people don't even know that these
> systems don't work correctly in blk-mq.  And they won't work correctly
> in any available configuration from 4.21, if we don't fix this problem.

So, when seen from userland, how it should behave isn't vague or
complicated.  For a given device and policy type, there can be only
one implementation active.  It doesn't make sense to have two weight
mechanisms active on one device, right?  So, the interface should only
present what makes sense to the user for both configuration knobs and
statistics, and that'd be a hard requirement because we don't want to
present confusing spurious information to userspace.

There seemd to have been significant misunderstandings as to what the
requirements are when this was discussed way back, so idk what the
good path forward is at this point.  Just keep the current names?

Thanks.

-- 
tejun

Powered by blists - more mailing lists