linux-kernel - Re: [RESEND][RFC] BFQ I/O Scheduler

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, 17 Apr 2008 13:14:07 +0200
From:	Fabio Checconi <fchecconi@...il.com>
To:	Aaron Carroll <aaronc@....unsw.edu.au>
Cc:	Paolo Valente <paolo.valente@...more.it>,
	Jens Axboe <jens.axboe@...cle.com>,
	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [RESEND][RFC] BFQ I/O Scheduler

> From: Aaron Carroll <aaronc@....unsw.edu.au>
> Date: Thu, Apr 17, 2008 08:24:09PM +1000
>
> Paolo Valente wrote:
> >In my opinion, the time-slice approach of cfq is definitely better 
> >suited than the (sector) budget approach for this type of workloads. On 
> >the opposite end, the price of time-slices is unfairness towards, e.g., 
> >threads doing sequential accesses. In bfq we were mainly thinking about 
> 
> How do you figure that?  This is a situation where time-slices work nicely,
> because they implicitly account for the performance penalty of poor access
> patterns.  The sequential-accessing processes (and the system overall) ends
> up with higher throughput.
> 

The unfairness is not WRT tasks generating poor access patterns.
If you have two tasks doing sequential accesses on two different
regions of the disk the exact amount of service they receive in the
same amount of time depends on the transfer rate of the disk on
that regions, and, depending on the media, it is not always the same.

We showed some example of that in the original post and it is quite
easy to try it out if you put two partitions at the ends of a disk
and you try to read from them concurrently.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/