Disk blocks for long periods
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
> 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?
More information about the linux-mtd