RE: [PATCH] mm: moving dirty pages balancing to pdfludh entirely
From: Ananiev, Leonid I
Date: Wed Jul 05 2006 - 15:49:17 EST
Nikita Danilov writes:
> Exactly to the contrary: as I explained to you, if you have more
devices
> than pdflush threads
I do not believe that Bret Towe has more devices than
MAX_PDFLUSH_THREADS=8.
> See how wbc.nr_to_write is set up by balance_dirty_pages().
It is number TO write but I said about number after what user has to
write-out all dirty pages.
> imagine that MAX_PDFLUSH_THREADS equals 1
Imagine that CONFIG_NR_CPUS=1 for smp.
Kernel has a lot of "big enough" constants.
Leonid
-----Original Message-----
From: Nikita Danilov [mailto:nikita@xxxxxxxxxxxxx]
Sent: Wednesday, July 05, 2006 11:07 PM
To: Ananiev, Leonid I
Cc: Bret Towe; Linux Kernel Mailing List
Subject: Re: [PATCH] mm: moving dirty pages balancing to pdfludh
entirely
Ananiev, Leonid I writes:
>
> Bret Towe writes:
> > if say some gtk app wants to write to disk it will freeze
> > until the usb hd is completely done
>
> The proposed patch fixes one real cause of long latency: if a user
Exactly to the contrary: as I explained to you, if you have more devices
than pdflush threads, your patch will result in all system doing IO as
slow as slowest devices in the system. In addition, if you have more
than MAX_PDFLUSH_THREADS processors, some of them cannot be used to
concurrently perform writeback.
> thread writes 1 byte only to disk it could happen that one has to
write
> all pages dirtied by all threads in the system and wait for it. The
See how wbc.nr_to_write is set up by balance_dirty_pages().
> patch is tested and gets real benefit on real systems. A common
system
> work is performed in common system thread but not in casual user
thread.
To understand the problem I am trying to attract your attention to,
imagine that MAX_PDFLUSH_THREADS equals 1. See what you get? BSD
(pagedaemon everybody waits upon). But Linux is not BSD, thankfully.
>
> The patch does not fix other (bazillion - 1) fictitious freezing
causes
> for imaginary configurations.
Yes, and all the world is VAX (var. "my benchmarking suite"), as they
used to say. :-)
>
> 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/