[PATCH] writeback daemons
authorAndrew Morton <akpm@zip.com.au>
Wed, 10 Apr 2002 04:29:47 +0000 (21:29 -0700)
committerLinus Torvalds <torvalds@penguin.transmeta.com>
Wed, 10 Apr 2002 04:29:47 +0000 (21:29 -0700)
commit1ed704e93c0ba1dd930f8a451765f054ba218f1b
tree690852d9b6892d0919119a57725c841b20573abd
parent9855b4a17d61f4c7642c02cb905eec99a6f2c061
[PATCH] 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.
include/linux/mm.h
include/linux/sched.h
mm/Makefile
mm/pdflush.c [new file with mode: 0644]