#7826 HIGH 9.1.0: jffs_mtd_gcd scheduling?

[Zarro Boogs per Child]

#7826: jffs_mtd_gcd scheduling?
---------------------------------+------------------------------------------
           Reporter:  cjb        |       Owner:  dwmw2        
               Type:  defect     |      Status:  new          
           Priority:  high       |   Milestone:  9.1.0        
          Component:  kernel     |     Version:  not specified
         Resolution:             |    Keywords:  cjbfor9.1.0  
        Next_action:  never set  |    Verified:  0            
Deployment_affected:             |   Blockedby:               
           Blocking:             |  
---------------------------------+------------------------------------------
Changes (by dsaxena):

 * cc: dilinger (added)


Comment:

 I am going through all kernel bugs marked as 9.1 or future release and
 updating their status, next action, etc in preparation of 9.1 bug
 scrubbing and future release planning.

 We have the following patch checked into our master repo that should
 help with this. Dilinger, can you send upstream and see if it is acked?


 {{{
 commit 6fca8739963a280efe5d6ec42123d408e9e88485
 Author: Andres Salomon <dilinger at debian.org>
 Date:   Tue Nov 18 21:39:47 2008 -0500

     jffs2: force the jffs2 GC daemon to behave a bit better

     I've noticed some pretty poor behavior on OLPC machines after bootup,
 when
     gdm/X are starting.  The GCD monopolizes the scheduler (which in turns
 means
     it gets to do more nand i/o), which results in processes taking much
 much
     longer than they should to start.

     As an example, on an OLPC machine going from OFW to a usable X (via
 auto-login
     gdm) takes 2m 30s.  The majority of this time is consumed by the
 switch into
     graphical mode.  With this patch, we cut a full 60s off of bootup
 time.  After
     bootup, things are much snappier as well.

     Note that we have seen a CRC node error with this patch that causes
 the machine
     to fail to boot, but we've also seen that problem without this patch.

     Signed-off-by: Andres Salomon <dilinger at debian.org>

 diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
 index 0fd792b..d27b60e 100644
 --- a/fs/jffs2/background.c
 +++ b/fs/jffs2/background.c
 @@ -95,13 +95,17 @@ static int jffs2_garbage_collect_thread(void *_c)
                         spin_unlock(&c->erase_completion_lock);


 -               /* This thread is purely an optimisation. But if it runs
 when
 -                  other things could be running, it actually makes things
 a
 -                  lot worse. Use yield() and put it at the back of the
 runqueue
 -                  every time. Especially during boot, pulling an inode in
 -                  with read_inode() is much preferable to having the GC
 thread
 -                  get there first. */
 -               yield();
 +               /* Problem - immediately after bootup, the GCD spends a
 lot
 +                * of time in places like jffs2_kill_fragtree(); so much
 so
 +                * that userspace processes (like gdm and X) are starved
 +                * despite plenty of cond_resched()s and renicing.
 Yield()
 +                * doesn't help, either (presumably because userspace and
 GCD
 +                * are generally competing for a higher latency resource -
 +                * disk).
 +                * This forces the GCD to slow the hell down.   Pulling an
 +                * inode in with read_inode() is much preferable to having
 +                * the GC thread get there first. */
 +               schedule_timeout_interruptible(msecs_to_jiffies(50));

                 /* Put_super will send a SIGKILL and then wait on the sem.
                  */
 }}}

-- 
Ticket URL: <http://dev.laptop.org/ticket/7826#comment:4>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system