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
______________________________________________________________________
next prev parent 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.