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] [day] [month] [year] [list]
Date:   Fri, 5 Jan 2018 09:28:27 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        ulf.hansson@...aro.org, broonie@...nel.org,
        linus.walleij@...aro.org, angeloruocco90@...il.com,
        bfq-iosched@...glegroups.com
Subject: Re: [PATCH IMPROVEMENT/BUGFIX 0/4] remove start-up time outlier
 caused by wrong detection of cooperating processes

On 12/20/17 4:38 AM, Paolo Valente wrote:
> Hi,
> the main patch in this series ("block, bfq: let a queue be merged only
> shortly after starting I/O") eliminates an outlier in the application
> start-up time guaranteed by BFQ. This outlier occurs more or less
> frequently, as a function of the characteristics of the system, and is
> caused by a wrong detection of so-called cooperating processes
> (details in the commit message).  This main patch is preceded by two
> patches that fix two bugs found while working on this problem.  The
> patch is then followed by a further, optimization patch, that removes
> an operation made superfluous by the main patch.
> 
> Jens, I've not forgotten our decision to make a patch that enables
> blkio stats (related to proportional-share policy) to not be enabled
> at boot, or when CFQ or BFQ modules are loaded. Just, we have already
> prepared the present patches, plus a few other patches for improving
> BFQ and fixing bugs, and I'd like to clear this backlog first.
> 
> In this respect, after a patch for boosting throughput more reliably
> with cooperating processes, I'll send out a patch to solve an
> important read starvation problem. If I'm not making a blunder, this
> problem affects every I/O scheduler in blk-mq. As a first step, I'll
> propose a fix for BFQ. If the fix is ok, I'm willing to port it to the
> other schedulers.

Added for 4.16, thanks.

-- 
Jens Axboe

Powered by blists - more mailing lists