The key concept here is that pdflush does not block on request queues
any more.  Instead, it circulates across the queues, keeping any
non-congested queues full of write data.  When all queues are full,
pdflush takes a nap, to be woken when *any* queue exits write
congestion.

This code can keep sixty spindles saturated - we've never been able to
do that before.

 - Add the `nonblocking' flag to struct writeback_control, and teach
   the writeback paths to honour it.

 - Add the `encountered_congestion' flag to struct writeback_control
   and teach the writeback paths to set it.

So as soon as a mapping's backing_dev_info indicates that it is getting
congested, bale out of writeback.  And don't even start writeback
against filesystems whose queues are congested.

 - Convert pdflush's background_writeback() function to use
   nonblocking writeback.

This way, a single pdflush thread will circulate around all the
dirty queues, keeping them filled.

 - Convert the pdlfush `kupdate' function to do the same thing.

This solves the problem of pdflush thread pool exhaustion.

It solves the problem of pdflush startup latency.

It solves the (minor) problem wherein `kupdate' writeback only writes
back a single disk at a time (it was getting blocked on each queue in
turn).

It probably means that we only ever need a single pdflush thread.

Use the new queue congestion detector in ext2_preread_inode().  Don't
try the speculative read if the read queue is congested.

Also, don't try it if the disk is write-congested.  Presumably it is
more important to get the dirty memory cleaned out.

The patch provides a means for the VM to be able to determine whether a
request queue is in a "congested" state.  If it is congested, then a
write to (or read from) the queue may cause blockage in
get_request_wait().

So the VM can do:

	if (!bdi_write_congested(page->mapping->backing_dev_info))
		writepage(page);

This is not exact.  The code assumes that if the request queue still
has 1/4 of its capacity (queue_nr_requests) available then a request
will be non-blocking.  There is a small chance that another CPU could
zoom in and consume those requests.  But on the rare occasions where
that may happen the result will mereley be some unexpected latency -
it's not worth doing anything elaborate to prevent this.

The patch decreases the size of `batch_requests'.  batch_requests is
positively harmful - when a "heavy" writer and a "light" writer are
both writing to the same queue, batch_requests provides a means for the
heavy writer to massively stall the light writer.  Instead of waiting
for one or two requests to come free, the light writer has to wait for
32 requests to complete.

Plus batch_requests generally makes things harder to tune, understand
and predict.  I wanted to kill it altogether, but Jens says that it is
important for some hardware - it allows decent size requests to be
submitted.

The VM changes which go along with this code cause batch_requests to be
not so painful anyway - the only processes which sleep in
get_request_wait() are the ones which we elect, by design, to wait in
there - typically heavy writers.


The patch changes the meaning of `queue_nr_requests'.  It used to mean
"total number of requests per queue".  Half of these are for reads, and
half are for writes.  This always confused the heck out of me, and the
code needs to divide queue_nr_requests by two all over the place.

So queue_nr_requests now means "the number of write requests per queue"
and "the number of read requests per queue".  ie: I halved it.

Also, queue_nr_requests was converted to static scope.  Nothing else
uses it.


The accuracy of bdi_read_congested() and bdi_write_congested() depends
upon the accuracy of mapping->backing_dev_info.  With complex block
stacking arrangements it is possible that ->backing_dev_info is
pointing at the wrong queue.  I don't know.

But the cost of getting this wrong is merely latency, and if it is a
problem we can fix it up in the block layer, by getting stacking
devices to communicate their congestion state upwards in some manner.

__set_page_dirty_buffers() is calling __mark_inode_dirty under
mapping->private_lock.

We don't need to hold ->private_lock across that call.  It's only there
to pin page->buffers.

This simplifies the VM locking heirarchy.

When I converted ext3 to use to use direct-to-BIO writeback for
data=writeback mode I forgot that we need to hold a transaction open on
behalf of MAP_SHARED pages.  The fileystem is BUGging in get_block()
because there is no transaction open.

So let's forget that idea for now and send data=writeback mode back to
ext3_writepage.

it is an ex-parrot

assorted compile fixes

mtdblock switched to use of gendisks + compile fixes

z2ram.c switched to use of gendisks

ataflop.c switched to use of gendisks

amiflop.c switched to use of gendisks

macroectomy a-la pf.c and pcd.c ones, ditto for passing pointers to
structures instead of minors.

pd.c fed through Lindent

dumb expansion of macro - it had #define CURRENT current_req

tapeblock never assignes anything to its elements of blk_size[][]; we could
not bother allocating it in the first place.

More trivial fixes: typos in partitions/check.c, block/floppy.c and
acorn/block/fd1772.c + replacement of #define with inline in block/floppy.c
(fd_eject()).

Some trivial fixes for some typos introduced by Al's gendisk changes..

 - missing comma in cdu31a
 - missing semicolon in cdu31a
 - comma instead of colon in gscd
 - semicolon instead of comma in mcd
 - missing closing bracket in sonycd535

From Andries.

From davem: replace `unsigned' with size_t.

into home.transmeta.com:/home/torvalds/v2.5/linux

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

(releases memory block after read out)

[note - more work needs to be done here, but this is better than
nothing -jgarzik]

floppies and CD's in /proc/partitions.

Some idiot (OK, it was me) broke free_area_init_node for
non discontigmem systems that call it directly (eg sparc64),
during a recent cleanup, thus invoking the wrath of DaveM.

I know Dave sent you a patch yesterday, but I think the BUG
statement in it will break anyone who just uses free_area_init
(eg any PC). So here's a portion of Dave's patch that should
fix things for everyone I think. Unfortunately my non-NUMA
test box is borked right now, but it just removes the BUG
statement from what he tested, and it's so simple that even
I couldn't screw this up (famous last words).

This code really needs some more cleanup work, but this will
fix it for now so everyone can do their work ...

into home.transmeta.com:/home/torvalds/v2.5/linux

swim_iop switched to use of gendisk

acorn floppy switched to use of gendisk

xpram switched to use of gendisk

nbd switched to use of gendisk

rd switched to use of gendisk

stram switched to use of gendisk

sonycd switched to use of gendisk; missing initcall restored