Subject: Re: pdflush question...
From: Robert Love <rml@tech9.net>
To: Daniel Blueman <daniel.blueman@gmx.net>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org
In-Reply-To: <14227.1062581053@www37.gmx.net>
References: <14227.1062581053@www37.gmx.net>
Content-Type: text/plain
Message-Id: <1062609171.7000.3.camel@boobies.awol.org>
Mime-Version: 1.0
Date: Wed, 03 Sep 2003 13:12:51 -0400
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1370
Lines: 37

On Wed, 2003-09-03 at 05:24, Daniel Blueman wrote:
> Is it worth having a kernel config option to vary the number of 'pdflush'
> kernel threads?

I suspect no.

> For embedded, systems with no swap and maybe uniproc (?), perhaps one
> pdflush kthread would do?

Yes.  Definitely.  In fact, I think that, for all systems, the initial
default should perhaps be one.

But note that the reason for n>1 pdflush threads is neither swap or
processor related.  The multiple threads can keep multiple block devices
busy, since one thread blocking on I/O will not affect another one.

I guess the real test would be to set MIN_PDFLUSH_THREADS to one and see
if one is enough for the average machines.  If the number quickly jumps
to 2 or more... then we know its a bad idea.

> Perhaps more generally, the number could be linked to the number of
> processors and/or swap devices or spindles- this would eliminate having to configure
> it, and improve downward and upward scaling, perhaps?

Number of spindles, yes.  But how do we know that?  And its just the
number of busy spindles, really.

I say we drop down to one.

	Robert Love


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/