[PATCH] VM buffer behaviour, was Re: [Wait!] pre4 is broken!

Stephen C. Tweedie (sct@redhat.com)
Tue, 16 Feb 1999 11:07:12 GMT


Hi,

On Mon, 15 Feb 1999 15:46:05 -0800 (PST), Simon Kirby <sim@netnation.com> said:

> While running "vmstat 1" in another console. It looked pretty happy until
> "rm" started to run -- it kept "rmming" forever, in fact. vmstat showed a
> solid ~850kb/sec being written out to disk (previously about 10MB/sec when
> the file was being created), and it wouldn't stop. The system was very
> responsive, however -- logging in to a new console, etc, was all pretty
> good.

> Luckily it didn't seem to destroy anything, so I'm guessing it's stuck
> somehow flushing out the same buffers over and over again.

It looks like it is simply being too aggressive about starting the
wakeup_bdflush(1) behaviour. This is the problem with such a patch: if
we make write buffering less aggressive then it is far too easy to lose
write throughput on larger machines.

Anyway, I have a couple of people currently testing or waiting to test
the patch below against 2.2.2-pre4. The wakeup_bdflush(1) test is now
conditional _only_ on the number of locked buffers, independently of
the number of dirty buffers. The more people who can try this before
2.2.2-pre4, the better.

More importantly, it adds the check in bdflush to refile locked
buffers on the clean list after IO. Linus, you missed this bit of the
patch from 2.2.2-pre4, and it is the most important part of it:
without that, it is impossible to know how many of the BUF_LOCKED
buffers are _really_ locked, and therefore how to throttle the writes
while keeping the IO queues full. There's no point releasing
2.2.2-pre4 without that bit of the patch: it will simply stop doing
anything useful (as Simon found) because the refile_buffer logic will
see there being far too many BUF_LOCKED buffers, even after the IO has
completed.

--Stephen

----------------------------------------------------------------
--- fs/buffer.c~ Tue Feb 16 11:52:10 1999
+++ fs/buffer.c Tue Feb 16 11:57:55 1999
@@ -877,8 +877,8 @@
* If too high a percentage of the buffers are dirty...
*/
if (nr_buffers_type[BUF_DIRTY] > too_many ||
- (size_buffers_type[BUF_DIRTY] + size_buffers_type[BUF_LOCKED])/PAGE_SIZE > too_large) {
- if (nr_buffers_type[BUF_LOCKED] > 2 * bdf_prm.b_un.ndirty)
+ size_buffers_type[BUF_DIRTY]/PAGE_SIZE > too_large) {
+ if (nr_buffers_type[BUF_LOCKED] > 3 * bdf_prm.b_un.ndirty)
wakeup_bdflush(1);
else
wakeup_bdflush(0);
@@ -1924,7 +1924,7 @@
#ifdef DEBUG
for(nlist = 0; nlist < NR_LIST; nlist++)
#else
- for(nlist = BUF_DIRTY; nlist <= BUF_DIRTY; nlist++)
+ for(nlist = BUF_LOCKED; nlist <= BUF_DIRTY; nlist++)
#endif
{
ndirty = 0;
@@ -1943,11 +1943,16 @@
}

/* Clean buffer on dirty list? Refile it */
- if (nlist == BUF_DIRTY && !buffer_dirty(bh) && !buffer_locked(bh))
- {
- refile_buffer(bh);
- continue;
- }
+ if (nlist == BUF_DIRTY && !buffer_dirty(bh)) {
+ refile_buffer(bh);
+ continue;
+ }
+
+ /* Unlocked buffer on locked list? Refile it */
+ if (nlist == BUF_LOCKED && !buffer_locked(bh)) {
+ refile_buffer(bh);
+ continue;
+ }

if (buffer_locked(bh) || !buffer_dirty(bh))
continue;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/