writeback daemons

This patch implements a gang-of-threads which are designed to be used for dirty data writeback. "pdflush" -> dirty page flush, or something.

The number of threads is dynamically managed by a simple demand-driven algorithm.

"Oh no, more kernel threads". Don't worry, kupdate and bdflush disappear later.

The intent is that no two pdflush threads are ever performing writeback against the same request queue at the same time. It would be wasteful to do that. My current patches don't quite achieve this; I need to move the state into the request queue itself...

The driver for implementing the thread pool was to avoid the possibility where bdflush gets stuck on one device's get_request_wait() queue while lots of other disks sit idle. Also generality, abstraction, and the need to have something in place to perform the address_space-based writeback when the buffer_head-based writeback disappears.

There is no provision inside the pdflush code itself to prevent many threads from working against the same device. That's the responsibility of the caller.

The main API function, `pdflush_operation()' attempts to find a thread to do some work for you. It is not reliable - it may return -1 and say "sorry, I didn't do that". This happens if all threads are busy.

One _could_ extend pdflush_operation() to queue the work so that it is guaranteed to happen. If there's a need, that additional minor complexity can be added.

Patch is against 2.5.8-pre3+ratcache+readahead+pageprivate

=====================================

@@ -589,6 +589,9 @@ static inline struct vm_area_struct * fi
 
 extern struct vm_area_struct *find_extend_vma(struct mm_struct *mm, unsigned long addr);
 
+extern int pdflush_operation(void (*fn)(unsigned long), unsigned long arg0);
+extern int pdflush_flush(unsigned long nr_pages);
+
 extern struct page * vmalloc_to_page(void *addr);
 
 #endif /* __KERNEL__ */

@@ -368,6 +368,7 @@ do { if (atomic_dec_and_test(&(tsk)->usa
 #define PF_MEMDIE	0x00001000	/* Killed for out-of-memory */
 #define PF_FREE_PAGES	0x00002000	/* per process page freeing */
 #define PF_NOIO		0x00004000	/* avoid generating further I/O */
+#define PF_FLUSHER	0x00008000	/* responsible for disk writeback */
 
 /*
  * Ptrace flags

@@ -14,6 +14,7 @@ export-objs := shmem.o filemap.o mempool
 obj-y	 := memory.o mmap.o filemap.o mprotect.o mlock.o mremap.o \
 	    vmalloc.o slab.o bootmem.o swap.o vmscan.o page_io.o \
 	    page_alloc.o swap_state.o swapfile.o numa.o oom_kill.o \
-	    shmem.o highmem.o mempool.o msync.o mincore.o readahead.o
+	    shmem.o highmem.o mempool.o msync.o mincore.o readahead.o \
+	    pdflush.o
 
 include $(TOPDIR)/Rules.make

-

Hi!

So... when we are low on free memory, we try to create more threads... Possible deadlock?
Pavel

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Nope. The number of threads is never allowed to fall below two, for this very reason.

If the machine is super-low on memory, attempts to start more threads fail (usually due to the 1-order allocation for the kernel stack). I've seen this happen. But the existing two threads are safe, and that's plenty to get the machine out of trouble.

-

Hi!

I thought this was the case. BTW do you need *two* threads for reliable operation, or is one enough?

Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

I chose two because we used to have two - kupdate and bdflush. But yes, surely one is sufficient. Added to the todo file.

-