[dm-devel] [PATCH] dm-kcopyd: monitor io activity

[Mikulas Patocka]

On Tue, 31 May 2011, Joe Thornber wrote:

> On Tue, May 31, 2011 at 10:12:24AM +0100, Alasdair G Kergon wrote:
> > On Tue, May 31, 2011 at 10:09:01AM +0100, Joe Thornber wrote:
> > > Different kcopyd clients have different performance requirements, for
> > > instance the initial sync of a new mirror leg may have less priority
> > > than a copy-on-write exception for a snapshot.  This isn't something
> > > we've addressed so far, but if you're starting to slow kcopyd down
> > > (i.e. so the mirror sync doesn't saturate the system), then I think
> > > you'll get some complaints from the snapshot users.

I think it's a good comment. We could make different throttles for 
different clases of clients --- i.e. have one throttle for mirrors, one 
for snapshots, one for multisnap, etc.

The variables "dm_kcopyd_throttle", "activity_spinlock", "num_io_jobs", 
"io_period", "total_period", "last_jiffies" could be placed into a 
structure and the structure could be moved to every module that uses 
kcopyd. Thus, the modules could be throttled independently.

> > Is it plausible to differentiate between the classes of clients,
> > and prioritise snapshot i/o above mirror or have different throttling
> > parameters?
> 
> Well I think it's plausible to have a priority field as part of the
> request structure.  This could be either a direct priority, or a
> 'class' mapping onto a throttling parameter as you suggest.  As long
> as we're careful to avoid starvation it shouldn't be too hard to
> implement.
> 
> In general I'd rather avoid introducing paramaters for the sys admin.

If you don't make a parameter, the whole idea of throttling is useless. 
The throttling should happen only at admin's request, never do it 
automatically. If we slow down I/O deliberately, people will surely come 
up with scenarios where it hurts performance.

> It's more work for them, and in my experience they rarely get set
> properly.  So is there a way to infer priorities for different
> clients?  Perhaps a function of number and size of recently submitted
> kcopyd jobs?

This is duplicating work of i/o scheduler. Such decisions should be made 
in the i/o scheduler and not in kcopyd.

> If one client has submitted a request to copy 64k of
> data and the other 1G does it always make sense to do the small job in
> a more timely manner?
> 
> - Joe

Mikulas