linux-kernel - Re: [PATCH 7/8] blk-wbt: add general throttling mechanism

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, 10 Nov 2016 20:36:41 +0100
From:   Jan Kara <jack@...e.cz>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org,
        hch@....de
Subject: Re: [PATCH 7/8] blk-wbt: add general throttling mechanism

On Wed 09-11-16 12:52:59, Jens Axboe wrote:
> On 11/09/2016 09:07 AM, Jens Axboe wrote:
> >On 11/09/2016 01:40 AM, Jan Kara wrote:
> >>>>So for devices with write cache, you will completely drain the device
> >>>>before waking anybody waiting to issue new requests. Isn't it too
> >>>>strict?
> >>>>In particular may_queue() will allow new writers to issue new writes
> >>>>once
> >>>>we drop below the limit so it can happen that some processes will be
> >>>>effectively starved waiting in may_queue?
> >>>
> >>>It is strict, and perhaps too strict. In testing, it's the only method
> >>>that's proven to keep the writeback caching devices in check. It will
> >>>round robin the writers, if we have more, which isn't necessarily a bad
> >>>thing. Each will get to do a burst of depth writes, then wait for a new
> >>>one.
> >>
> >>Well, I'm more concerned about a situation where one writer does a
> >>bursty write and blocks sleeping in may_queue(). Another writer
> >>produces a steady flow of write requests so that never causes the
> >>write queue to completely drain but that writer also never blocks in
> >>may_queue() when it starts queueing after write queue has somewhat
> >>drained because it never submits many requests in parallel. In such
> >>case the first writer would get starved AFAIU.
> >
> >I see what you are saying. I can modify the logic to ensure that if we
> >do have a waiter, we queue up others behind it. That should get rid of
> >that concern.
> 
> I added that - if we currently have a waiter, we'll add ourselves to the
> back of the waitqueue and wait.

OK, sounds good to me. If the write queue draining will show to be an
issue, it will be at least clearly visible with this logic.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR