RE: [PATCH] mm: moving dirty pages balancing to pdfludh entirely

[Ananiev, Leonid I]

Nikita Danilov writes:
> suppose you have more than MAX_PDFLUSH_THREADS
Do you consider that the drawback of the patch is in that the value
MAX_PDFLUSH_THREADS is not well known high or this limit is not deleted
at all? The limit could be deleted after patching because the line 
+	if (writeback_in_progress(bdi)) {
keeps off creating extra pdflush threads.

Leonid
-----Original Message-----
From: Nikita Danilov [mailto:nikita@xxxxxxxxxxxxx] 
Sent: Wednesday, July 05, 2006 2:17 PM
To: Ananiev, Leonid I
Cc: Linux Kernel Mailing List
Subject: Re: [PATCH] mm: moving dirty pages balancing to pdfludh
entirely

Ananiev, Leonid I writes:
 > 
 > 
 > Nikita Danilov writes:
 > > Doing large amounts of writeback from pdflush threads makes
situation
 > > only worse: suppose you have more than MAX_PDFLUSH_THREADS devices
on
 > > the system, and large number of writing threads. If some devices
 > become
 > > congested, then *all* pdflush threads may easily stuck waiting on
 > queue
 > > congestion and there will be no IO going on against other devices.
 > This
 > > would be especially bad, if system is a mix of slow and fast
devices.
 > 
 > *all* pdflush threads may NOT waiting on single queue because
function

I specifically mentioned that multiple deviceS become congested: each
pdlush thread stuck on its own congested device, the rest of devices is
idle.

 > balance_dirty_pages() tests it:
 > 
 > 	if (writeback_in_progress(bdi))
 > 		return;		/* pdflush is already working this queue
 > */
 > 
 > > Yes, that was silly proposal. I think your patch contains very
useful
 > > idea, but it cannot be applied to all file systems. Maybe
 > > wait-for-pdflush can be made optional, depending on the file system
 > > type?
 > 
 > I suppose MS DOS was the last operating system which had considered
 > that parallelism is not applicable.

It also was the last file system that supported the only type of file
system, with asumptions about file system behaviour hard coded into its
design. :-)

 > 
 > Leonid

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