Messages in this thread | | | From | Chris Snook <> | Date | Sat, 11 Jul 2009 04:16:13 -0400 | Subject | Re: Suggested code change : Simple : Scale pdflush threads from desktop to server |
| |
On Fri, Jul 10, 2009 at 9:25 PM, Mitchell Erblich<erblichs@earthlink.net> wrote: > Group, > > pdflush threads clean dirty pages > > Under the past simple assumption that a greater number of > page daemon threads will have the TENDENCY to clean > the pages faster. > > Another assumption is that a server will have at least 2x / 4x the > number of drives and memory, so allocating more pdflush() threads > makes sense.
That's a rather sweeping generalization.
> Relying on a recent change, code base on whether the system is > a desktop or a server, scale the number of pdthreads() which would > result in the below code change. > > The suggestion is to double the MIN number of threads and set the > MAX number to 4x. > > ./mm/pdflush.c > /* Scale for a server */ > #define MIN_PDFLUSH_THREADS 4 /* 2x desktop value > */ > #define MAX_PDFLUSH_THREADS 32 /* 4x desktop value > */
So, you're taking a well-established and empirically validated set of constants, and changing it only in the case where users are least tolerant of change? I agree that the existing pdflush tuning is a bit of a kludge, but this just adds more noise to the data we need to analyze and optimize pdflush.
> /* > * secondary suggestion is to add a DEBUG type /var/log/system > messages that > * will rate limit independent of desktop or server. > */ > > else if (nr_pdflush_threads == MAX_PDFLUSH_THREADS) { > /* optional PDFLUSH msg */ > if (printk_ratelimit() { > printk(KERN_INFO > "MAX_PDFLUSH_THREADS Limited\n"); > } > }
Log messages, even at debug level, for normal conditions are a really bad idea.
pdflush definitely needs work, but twiddling constants will, at best, optimize it for a small subset of the user base for a brief period of time. We really need patches that do intelligent things based on system resources and load, and we need data to support them.
-- Chris -- 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/
| |