linux-kernel - Re: [PATCHSET block/for-next] IO cost model based work-conserving porportional controller

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]

Message-ID: <20190906145826.GL2263813@devbig004.ftw2.facebook.com>
Date:   Fri, 6 Sep 2019 07:58:26 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     Jens Axboe <axboe@...nel.dk>, newella@...com, clm@...com,
        Josef Bacik <josef@...icpanda.com>, dennisz@...com,
        Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>, kernel-team@...com,
        cgroups@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
        kafai@...com, songliubraving@...com, yhs@...com,
        bpf@...r.kernel.org
Subject: Re: [PATCHSET block/for-next] IO cost model based work-conserving
 porportional controller

Hello, Paolo.

On Fri, Sep 06, 2019 at 11:07:17AM +0200, Paolo Valente wrote:
> email.  As for the filesystem, I'm interested in ext4, because it is
> the most widely used file system, and, with some workloads, it makes

Ext4 can't do writeback control as it currently stands.  It creates
hard ordering across data writes from different cgroups.  No matter
what mechanism you use for IO control, it is broken.  I'm sure it's
fixable but does need some work.

That said, read-only tests like you're doing should work fine on ext4
too but the last time I tested io control on ext4 is more than a year
ago so something might have changed in the meantime.

Just to rule out this isn't what you're hitting.  Can you please run
your test on btrfs with the following patchset applied?

 http://lkml.kernel.org/r/20190710192818.1069475-1-tj@kernel.org

And as I wrote in the previous reply, I did run your benchmark on one
of the test machines and it did work fine.

Thanks.

-- 
tejun