On Mon, Nov 29 2010 at 5:05pm -0500,
Darrick J. Wong <djwong@us.ibm.com> wrote:
I share Neil's concern about having to track such fine grained
additional state in order to make the FS behave somewhat better. What
are the _real_ fsync-happy workloads which warrant this optimization?
That concern aside, my comments on your proposed DM changes are inlined below.
You're checking all devices in a table rather than all devices that will
receive a flush. The devices that will receive a flush is left for each
target to determine (target exposes num_flush_requests). I'd prefer to
see a more controlled .iterate_devices() based iteration of devices in
each target.
dm-table.c:dm_calculate_queue_limits() shows how iterate_devices can be
used to combine device specific data using a common callback and a data
pointer -- for that data pointer we'd need a local temporary structure
with your 'max' and 'samples' members.
You're missing important curly braces for the else in your dm_wq_work()
change...
But the bio-based call to measure_flushes() (dm_wq_work's call) should
be pushed into __split_and_process_bio() -- and maybe measure_flushes()
could grow a 'struct dm_table *table' argument that, if not NULL, avoids
getting the reference that __split_and_process_bio() already has on the
live table.
Mike
--