Mailinglist Archive: packet-writing (59 mails)

[Jens Axboe <axboe@xxxxxxx>]

On Sat, Sep 09 2000, adam@xxxxxxxxxxxx wrote:
> 	however the write would freeze machien for seconds (as long
> 	as 30 sec or even min at time) not even mouse would move then.

Just a heads up on this bug, I've fixed it now. The problem was that
cd-rw is a slow writer, as compared to a hard drive. I've maintained
a patch on the side for the regular kernel, that batches freeing
of requests once they are completed. That means once the request
free list is empty, we wait until a certain fraction of the total
requests are available before waking anyone up and handing them a
free slot. This works well when a queue is under pressure because
it provides some rudimentary flow control and allows the elevator
to do a better job at merging new buffers.

Back to the point -- for cd-rw, completing 16 requests can take a _lot_
of time. During this time, kflushd and kupdated would often be stuck
for long periods of time waiting for a slot. No buffers could thus
be flushed. Eek. For packet writing, we now wake for every free. There
are still some stalls because it is slow (try using a dvd-ram, you'll
see the same behaviour). But the stalls are much smaller now, around
one second every once in a while. Hopefully I can fix this too.

> 	- the data written onto cd is corrupted. for example

And a second heads up, I think I've nailed this one as well. I need
to do some more testing to be sure, though.

Unrelated info -- there's a rather severe bug in 0.0.2c that causes
buffers written to cd-rw not to be freed. Pretty stupid one too, the
folks on low memory machines will surely notice. A quick fix for that
is to move the atomic_inc(&bh->b_state) in the pkt_init_bh function
inside the if (bh->b_private == pd):

	if (bh->b_private == pd) {
		atomic_inc(&bh->b_count);
		bh->b_end_io = pkt_end_io_write;
	}

-- 
* Jens Axboe <axboe@xxxxxxx>
* SuSE Labs