Disk blocks for long periods

[Joakim Tjernlund]

> David Woodhouse said:
> > DGE at 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?
> 
> It is running because of the
>         wake_up(&chip->wq);
> at the end of do_write_oneword(). So it wakes up for every word written.
> 
> With the old code (cfi_cmdset_0002.c 1.56 and before) the next chance it 
> gets to run is when cfi_udelay() is called during the next 
> do_write_oneword(). Unfortunately, it can't start erasing because 
> chip->state is FL_WRITING, so it puts itself back on the wait queue. The
> wake_up() at the end of do_write_oneword() wakes it up again, but it
> doesn't run until the cfi_delay() in the _next_ call to do_write_oneword().
> So it runs and puts itself back on the wait queue for every call to 
> do_write_oneword(). Eventually all the words are written, it wakes up to 
> find FL_READY and starts the erase. Without the one jiffie delay in 
> cfi_delay() each time it wouldn't have been as bad, but erase going off 
> and back on the wait queue several thousand times still doesn't seem right.

You can move the wake_up() call up one step(xxxx_write_words()) and call it just before 
you leave that function. I tried that and it's a improvement(note, I using buffer writes, so
word writes should see an even better improvement), but that will also
hold reads back(not that I noticed anything) until xxx_write_words has completed. 
We can fix that by having separate wait queues for read and erase.

   Jocke