Re: Disk blocks for long periods

[David Woodhouse <dwmw2@infradead.org>]

DGE@sixnetio.com said:
> The cfi_udelay() call is part of the problem, since it lets other
> processes run, and the one that runs is the erasing process, but it
> can't do anything except slow things down since the flash  is busy
> writing.

The erasing process should be sitting in TASK_UNINTERRUPTIBLE and on the 
chip's wait queue, waiting to be woken when the chip becomes available. Why 
is it running?

> What the erasing process does seem to do (and  I don't understand why)
> is cause current->need_resched to be set for every call to
> cfi_udelay(), so it calls schedule_timeout(1)  and sleeps for a whole
> jiffie. 

Sleeping for a whole jiffie is bad. We should udelay() and yield() as you 
point out; there's no reason to use schedule_timeout() and hence stop 
ourself from being woken immediately if there's not really anything else to 
run. I've committed that change to CVS.

I don't understand why need_resched is being set either, though. 

Adding cfi_udelay() to do_write_oneword() is dangerous. You may trigger a
bug that's actually already there. ISTR there's a time limit on the 'unlock
bypass' mode, and if you schedule() you may find that the chip is no longer 
in that mode when you return.

Another thing you might want to do if you really care about write 
performance is copy the logic for calculating word_write_time from the 
cfi_cmdset_0001 driver.

--
dwmw2