Chapter 17: Data Synchronization
pdflushis started with the usual kernel thread mechanisms:
mm/pdflush.c
static void start_one_pdflush_thread(void)
{
kthread_run(pdflush, NULL, "pdflush");
}
start_one_pdflushstarts a singlepdflushthread — however, the kernel uses several threads at the
same time in general, as you will see below. It should be noted that a specificpdflushthread isnot
always responsible for the same block device. Thread allocation may vary over time simply because the
number of threads is not constant and differs according to system load.
In fact, the kernel starts the specific number of threads defined inMIN_PDFLUSH_THREADSwhen it initial-
izes thepdflushsubsystem. Typically, this number is 2 so that in a normally loaded system, two active
instances ofpdflushappear in the task list displayed byps:
wolfgang@meitner>ps fax
2? S< 0:00 [kthreadd]
...
206? S 0:00 _ [pdflush]
207? S 0:00 _ [pdflush]
...
There is a lower and an upper limit to the number of threads.MAX_PDFLUSH_THREADSspecifies the
maximum number ofpdflushinstances, typically 8. The number of concurrent threads is held in the
nr_pdflush_threadsglobal variable, but no distinction is made as to whether the threads are currently
active or sleeping. The current value is visible to userspace in/proc/sys/vm/nr_pdflush_threads.
The policy for when to create and destroypdflushthreads is simple. The kernel creates a new thread
if no idle thread has been available for 1 second. In contrast, a thread is destroyed if it has been idle for
more than 1 second. The upper and lower limits on the number of concurrentpdflushthreads defined
inMIN_PDFLUSH_THREADS(2) andMAX_PDFLUSH_THREADS(8) are always obeyed.
Why is more than one thread required? Modern systems will be typically equipped with more than one
block device. If many dirty pages exist in the system, it is the kernel’s job to keep these devices as busy
as possible with writing back data. Queues of different block devices are independent of each other, so
data can be written in parallel. Data transfer rates are mainly limited by I/O bandwidth, not CPU power
on current hardware. The connection betweenpdflushthreads and writeback queues is summarized
in Figure 17-2. The figure shows that a dynamically varying number ofpdflushthreads feeds the block
devices with data that must be synchronized with the underlying block devices. Notice that a block
device may have more than one queue that can transfer data, and that apdflushthread may either serve
all queues or just a specific one.
Former kernel versions only employed a single flushing daemon (which was then calledbdflush), but
this led to a performance problem: If one block device queue was congested because too many writeback
operations were pending, other queues fordifferentdevices could not be fed with new data anymore.
They remained idle, which can be a good thing on a summer vacation, but certainly not for block devices
if there is work to do. This problem is solved by the dynamical creation and destruction ofpdflushkernel
threads, which allows for keeping many queues busy in parallel.
