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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
