Re: Disk blocks for long periods

["Joakim Tjernlund" <Joakim.Tjernlund@lumentis.se>]

> joakim.tjernlund@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@sixnetio.com