Is it worth having a kernel config option to vary the number of 'pdflush'
kernel threads?
For embedded, systems with no swap and maybe uniproc (?), perhaps one
pdflush kthread would do?
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?
--
Daniel J Blueman
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualit?tssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
Daniel Blueman <[email protected]> wrote:
>
> Is it worth having a kernel config option to vary the number of 'pdflush'
> kernel threads?
>
> For embedded, systems with no swap and maybe uniproc (?), perhaps one
> pdflush kthread would do?
Probably it should just be set to one by default anyway. One pdflush is
good at serving lots of spindles.
> 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?
Well the kernel will create up to eight pdflush instances according to the
current load. That kinda works.
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