calc. of currspeed in md.c code in 2.4.20

calc. of currspeed in md.c code in 2.4.20

[Peter T. Breuer]

Can you shed some light on this for me?

currspeed =
 (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1;

jiffies is divided by HZ here, which results in a quantity of dimension
time-squared!

I could understand it (better) if jiffies were multiplied by HZ.

Peter

Re: calc. of currspeed in md.c code in 2.4.20

[Neil Brown]

On Wednesday May 14, ptb@it.uc3m.es wrote:
> 
> Can you shed some light on this for me?
> 
> currspeed =
>  (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1;
> 
> jiffies is divided by HZ here, which results in a quantity of dimension
> time-squared!
> 
> I could understand it (better) if jiffies were multiplied by HZ.
> 
> Peter

HZ == jiffies/second

so jiffies / HZ == jiffies / (jiffies/seconds) == seconds.

NeilBrown

Re: calc. of currspeed in md.c code in 2.4.20

[Paul Clements]

"Peter T. Breuer" wrote:
> 
> Can you shed some light on this for me?
> 
> currspeed =
>  (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1;
> 
> jiffies is divided by HZ here, which results in a quantity of dimension
> time-squared!
> 
> I could understand it (better) if jiffies were multiplied by HZ.

Just curious, but are you looking at this because the speed calculations
break when using a bitmap to resync? I realized this problem a few days
ago, but I'm not sure how to solve it, yet...

I think we might need two counters, one for the actual resync progress
(to display the progress bar, and show actual resync speed) and the
other to throttle I/O if actual I/O becomes too fast...

--
Paul

Re: calc. of currspeed in md.c code in 2.4.20

[Peter T. Breuer]

"A month of sundays ago Paul Clements wrote:"
> "Peter T. Breuer" wrote:
> > 
> > Can you shed some light on this for me?
> > 
> > currspeed =
> >  (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1;
> > 
> > jiffies is divided by HZ here, which results in a quantity of dimension
> > time-squared!
> > 
> > I could understand it (better) if jiffies were multiplied by HZ.
> 
> Just curious, but are you looking at this because the speed calculations
> break when using a bitmap to resync? I realized this problem a few days

Exactly so.

> ago, but I'm not sure how to solve it, yet...

Pushing speed_min up is a workaround.

> I think we might need two counters, one for the actual resync progress
> (to display the progress bar, and show actual resync speed) and the
> other to throttle I/O if actual I/O becomes too fast...

Possibly.  There are a large number of possible solutions, but until
I can understand what the speed calculation is supposed to be doing, I
find myself unable to pick out a way forward.


Peter

Re: calc. of currspeed in md.c code in 2.4.20

[Peter T. Breuer]

"Peter T. Breuer wrote:"
> > ago, but I'm not sure how to solve it, yet...
> 
> Pushing speed_min up is a workaround.

Correct me if this seems silly, but we could push speed_min up to equal
speed_max (or close) in the intervals in which the resync is skipping
sectors rather than syncing them. It does know.

Then nobody would have to change the (to me inscrutable) speed
calculation and throttling loop.

OTOH it would be nicer to have limits per device.

> > I think we might need two counters, one for the actual resync progress
> > (to display the progress bar, and show actual resync speed) and the
> > other to throttle I/O if actual I/O becomes too fast...


Peter

Re: calc. of currspeed in md.c code in 2.4.20

[Paul Clements]

"Peter T. Breuer" wrote:
 
> Correct me if this seems silly, but we could push speed_min up to equal
> speed_max (or close) in the intervals in which the resync is skipping
> sectors rather than syncing them. It does know.

But as soon as it hits the disk again, it's going to go to sleep,
because the resync speed up to that point (when there was no real I/O)
will be so high that it'll be way over the limits.

--
Paul

Re: calc. of currspeed in md.c code in 2.4.20

[Peter T. Breuer]

"A month of sundays ago Paul Clements wrote:"
> "Peter T. Breuer" wrote:
>  
> > Correct me if this seems silly, but we could push speed_min up to equal
> > speed_max (or close) in the intervals in which the resync is skipping
> > sectors rather than syncing them. It does know.
> 
> But as soon as it hits the disk again, it's going to go to sleep,
> because the resync speed up to that point (when there was no real I/O)
> will be so high that it'll be way over the limits.

It'll be over the (newly set back to normal) minimum, but not over the
maximum. I don't have the code in sight at the moment ... doesn't it
use the max as a highwater mark, then?

Anyway, one could take the min back down to normal slowly.  Halving the
difference every group of sectors resynced might be OK.

Peter