Disk blocks for long periods

Joakim Tjernlund joakim.tjernlund at lumentis.se
Tue Aug 6 11:09:12 EDT 2002


> 
> joakim.tjernlund at lumentis.se said:
> 
> > Have you tried to use cfi_udelay(chip->word_write_time) 
> > instead of udelay(chip->word_write_time)? That will at least 
> > let other processes run, won't it? 
> 
> 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. 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.

hmm, I just noticed that the BIG kernel lock is held while the
erasing thread executes, since kupdate takes it in sync_old_buffers()
(if I understand this code correctly). Maybe that is causing
current->need_resched to be set?

Also, is it not a bad idea to hold the kernel lock for, possibly, seconds while
erasing sectors?

> 
> By calling cfi_udelay() at the _end_ of the write of each word,
> it still allows the call to schedule_timeout() to happen, but
> at a time when the chip state allows other mtd processes operations,
> such as erase, to use it, so the one jiffie doesn't happen
> for every word written. The word writes are short (10 us typical,
> 360 us worst case for my chip), so not scheduling during the write
> is not so bad.

I assume your chip does not support buffered writes? or is it just do_write_one_word()
that is causing the log delays?

 Jocke





More information about the linux-mtd mailing list