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:	Sat, 20 Feb 2016 12:02:33 +0100
From:	Paolo Valente <paolo.valente@...aro.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Fabio Checconi <fchecconi@...il.com>,
	Arianna Avanzini <avanzini.arianna@...il.com>,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>, broonie@...nel.org
Subject: Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler


Il giorno 20/feb/2016, alle ore 11:23, Paolo Valente <paolo.valente@...aro.org> ha scritto:

> Hi
> 
> 
> If both processes reach ~100MB/s during their service slot, then, with
> both a budget- and time-based policy, we can meet the above bandwidth
> requirements by just assigning 9 and 1 as weights to A and B,
> respectively (the weight sum equals 10, thus A gets (9/10)*100 MB/s
> and B gets (1/10)*100 MB/s). Things change considerably if, e.g., the
> already penalized process B may get a lower throughput while it is
> served. This may happen to B systematically, as a function of the
> locality of its I/O pattern and of the characteristics of the
> rotational or non-rotational device. To mention a very simple yet
> still realistic scenario, it is enough that the storage resource is an
> HDD, and that B alternatively reads a large file from the inner zones
> and a large file from the outer zones of the HDD. For example, suppose
> that, regardless of whether the policy is budget- or time-based, B
> reaches a throughput equal to ~70MB/s during some budget/time slots,
> and to ~100MB/s during other budget/time slots. On the other hand, A
> always reaches ~100MB/s while it is served.
> 

Just one note, in case it is not clear, about how the bandwidth
provided to a process depends on the weights and the scheduler.

With a budget-based scheduler, the bandwidth provided to a process
with weight w is equal to:
( w/(sum of the weights of the processes doing I/O) ) * (total bandwidth)

With a time-based scheduler, it is equal to:

( fraction of the time during which the process is in service ) *
  (bandwidth reached by the process while in service) =
( w/(sum of the weights of the processes doing I/O) ) *
  (bandwidth reached by the process while in service)

Thanks,
Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ