All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aras Vaichas <arasv@magtech.com.au>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "dwmw2@infradead.org" <dwmw2@infradead.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"dilinger@debian.org" <dilinger@debian.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"dilinger@queued.net" <dilinger@queued.net>
Subject: Re: [patch 4/9] jffs2: force the jffs2 GC daemon to behave a bit better
Date: Tue, 17 Mar 2009 10:28:49 +1100	[thread overview]
Message-ID: <49BEE0B1.7020507@magtech.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0902121016250.19761@lnxricardw.se.axis.com>

Ricard Wanderlof wrote:
> On Wed, 11 Feb 2009, akpm@linux-foundation.org wrote:
>
>   
>> 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.
>>     
>
> Can't really comment on how well the patch works, but we've also noticed a 
> similar slowdown on our systems during startup, so the idea as such is 
> welcome at any rate.
>   
I just posted a message to linux-arm-kernel regarding a similar problem 
I have an at91rm9200 based machine with NAND and JFFS2.

I suspected that garbage collection was causing delays of up to 3+ 
seconds during which time my watchdog patting daemon was not being 
scheduled ...

This was causing the watchdog timer to reset my machine but *only* when 
it was under significant NAND load  i.e. boot time, loading up the main 
application while GCD was running.

My solution was to double the watchdog timeout.

Aras

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

  reply	other threads:[~2009-03-16 23:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 21:27 [patch 4/9] jffs2: force the jffs2 GC daemon to behave a bit better akpm
2009-02-12  9:17 ` Ricard Wanderlof
2009-03-16 23:28   ` Aras Vaichas [this message]
2009-03-17  1:23     ` [patch 4/9] jffs2: force the jffs2 GC daemon to behave a bitbetter Reuben Dowle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49BEE0B1.7020507@magtech.com.au \
    --to=arasv@magtech.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=dilinger@debian.org \
    --cc=dilinger@queued.net \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.