[lkml]   [2018]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] block: BFQ default for single queue devices
On 10/5/18 2:16 AM, Jan Kara wrote:
> On Thu 04-10-18 15:42:52, Bart Van Assche wrote:
>> What I think is missing is measurement results for BFQ on a system with
>> multiple CPU sockets and against a fast storage medium. Eliminating
>> the host lock from the SCSI core yielded a significant performance
>> improvement for such storage devices. Since the BFQ scheduler locks and
>> unlocks bfqd->lock for every dispatch operation it is very likely that BFQ
>> will slow down I/O for fast storage devices, even if their driver only
>> creates a single hardware queue.
> Well, I'm not sure why that is missing. I don't think anyone proposed to
> default to BFQ for such setup? Neither was anyone claiming that BFQ is
> better in such situation... The proposal has been: Default to BFQ for slow
> storage, leave it to deadline-mq otherwise.

Hi Jan,

How do you define slow storage? The proposal at the start of this thread
was to make BFQ the default for all block devices that create a single
hardware queue. That includes all SATA storage since scsi-mq only
creates a single hardware queue when using the SATA protocol. The
proposal to make BFQ the default for systems with a single hard disk
probably makes sense but I am not sure that making BFQ the default for
systems equipped with one or more (SATA) SSDs is also a good idea.
Especially for multi-socket systems since BFQ reintroduces a queue-wide
lock. As you know no queue-wide locking happens during I/O in the
scsi-mq core nor in the blk-mq core.


 \ /
  Last update: 2018-10-06 05:13    [W:0.088 / U:17.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site