lkml.org 
[lkml]   [2008]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH] jffs2: force the jffs2 GC daemon to behave a bit better
    Date

    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@debian.org>
    ---
    fs/jffs2/background.c | 18 +++++++++++-------
    1 files changed, 11 insertions(+), 7 deletions(-)

    diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
    index 8adebd3..f38d557 100644
    --- a/fs/jffs2/background.c
    +++ b/fs/jffs2/background.c
    @@ -95,13 +95,17 @@ static int jffs2_garbage_collect_thread(void *_c)
    schedule();
    }

    - /* 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.
    */
    --
    1.5.6.5


    \
     
     \ /
      Last update: 2008-11-02 19:17    [W:0.024 / U:62.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site