lkml.org 
[lkml]   [2009]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] aoe: add barrier support
On Fri, Oct 09 2009, Ed Cashin wrote:
> This patch allows the aoe driver to support barrier bios by draining
> the current set of outstanding AoE commands and then issuing an ATA
> flush command. If the barrier contains I/O, that I/O is then
> performed, followed by a final ATA flush command.

Good, that's exactly how libata/ide works as well.

> This aoe driver differs from most block device drivers in that it does
> not handle I/O requests but handles bios, providing a make_request_fn
> to the block layer.
>
> The implementation makes the make_request_fn sleep to wait for any
> in-progress barrier to finish, and it sleeps waiting for the ATA flush
> to complete. I expect the process using make_request_fn to be
> something like "cp", in which case sleeping will not interfere with
> the performance characteristics of any unrelated aoe devices in the
> system. That hasn't been tested yet, though, and I'm concerned that
> putting pdflush to sleep could interfere with dirty data flushing on
> other aoe devices. Any comments about this issue would be
> appreciated.

pdflush doesn't exist anymore, the per-bdi thread may block without
causing any problems.

> Some debugging code remains in this patch for testing purposes, marked
> with "XXXdebug". This code allows barrier handling to be turned off
> and on and to be traced. Turning barrier support on and off is only
> supported on module load. This testing feature will not be a part of
> the final barrier support for aoe.

Sounds good.

> Jens Axboe suggests that code that we know can sleep should use
> spin_lock_irq instead of spin_lock_irqsave. Even though the latter is
> harmless, it also adds no value. This patch sneaks a few such lock
> changes in. Please comment if you think the change from
> spin_lock_irqsave to spin_lock_irq should be split out of the final
> version of this patch.

While I (obviously) think that is a good idea, you should not include it
in this patch. Patches should generally only do just one thing.

--
Jens Axboe



\
 
 \ /
  Last update: 2009-10-10 12:47    [W:0.028 / U:26.376 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site