Disk blocks for long periods
Joakim Tjernlund
Joakim.Tjernlund at lumentis.se
Tue Aug 6 17:06:01 EDT 2002
> joakim.tjernlund at lumentis.se said:
>
> > 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?
>
> If it is doing that, it doesn't seem right to me. But I
> thought jffs2/mtd bypassed the kernel buffers, so maybe
> kupdate and sync_old_buffers() are not involved here? I don't
> know much about this.
hmm, just remembered that a spin_lock() is NOP on Uni Processor computers.
Kupdate does the erasing and puts a CLEANMARKER on it when its
done. Just follow sync_old_buffers() until it ends up in jffs2_write_super()
BTW
jffs2_mark_erased_blocks() also checks the newly erased block for
0xffffffff by reading the EB back. Removing this test improves my litte test case
I wrote about in my previous post to the mtd list. The max copy time is reduced
from 20 seconds to 15 seconds.
Jocke
>
> > I assume your chip does not support buffered writes? or is it
> > just do_write_one_word() that is causing the log delays?
>
> No, it doesn't support buffered writes. The long delay I saw
> comes from sleeping for a jiffie during each call to
> do_write_oneword().
I tried your patch and it improved my write times as well. Thanks
>
> Dave Ellis
> dge at sixnetio.com
More information about the linux-mtd
mailing list