[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH 1/2] dm-kcopyd: introduce per-module throttle structure



On Fri, Jun 03 2011 at  7:01am -0400,
Joe Thornber <thornber redhat com> wrote:

> On Thu, Jun 02, 2011 at 03:55:16PM -0400, Mikulas Patocka wrote:
> > > iv) you haven't explained how the sys admin works out the correct
> > > throttle value.
> > 
> > There is no "correct" value. The "correct" value depends on how important 
> > is copying itself v.s. other i/o.
> 
> So who is going to set this?  Do you really have no advice for them
> beyond 'there is no correct value'?
> 
> > In theory (if disk scheduler were perfect), we wouldn't need any 
> > throttling. The disk scheduler should recognize that the kcopyd process is 
> > sending way more requests than any other process and should lower the 
> > i/o priority of kcopyd process.
> > 
> > In practice, the disk scheduler doesn't do it well, so kcopyd hurts the 
> > users. If you want an automated fix, fix the disk scheduler. But don't put 
> > disk scheduler logic into device mapper --- it dosn't belong there.
> 
> I totally agree with these two paragraphs.  Any throttling you add to
> kcopyd is always going to be a hack.

Wouldn't it be better to tie in to the block layer's new throttling
infrastructure that Vivek added?  Possibly expose a callback that
enables kcopyd consuming devices to throttle kcopyd as a side-effect of
the higher-level throttle?

Mike


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]