Messages in this thread Patch in this message | | | From | "Stephen C. Tweedie" <> | Subject | [PATCH] VM buffer behaviour, was Re: [Wait!] pre4 is broken! | Date | 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/
| |