I was trying to see how __make_request throttles a fast writing process
from overrunning a slow device. So I took Alessandro Rubini's spull.c
code from his device driver book (2nd edition) and ran it in "pseudo irq"
mode. What the driver does basically is to schedule an alarm in its
request service function (spull_irqdriven_request) and return immediately
without calling end_request. And when the alarm fires it finishes the IO
by calling end_request(1). I made the following change to the driver:
1. make the ram disk size infinite by setting blk_size[MAJOR_NR]=NULL.
2. disable the actual copying to/from the ram disk by commenting out
spull_transfer in the spull_irqdriven_request function.
I load the driver with a 3 second delay for the alarm. So basically, the
driver simulates a "very slow" device that takes 3 seconds to service
each request (without actually doing anything). Now I do:
dd if=/dev/zero of=/dev/pda bs=1024 count=1000000
What I expect is that the kernel will quickly stop dd after all 128 (64
on machines with less than 32MB of ram) free request slots are taken.
Of course it will take forever for dd to finish. But what happened is
that the system quickly becomes unusable. It still handles a request
every 3 seconds but is otherwise oblivious of any input (I can still
switch virtual console but that's it). Is this the expected behavior of
2.4 or am I just doing something stupid? Your insight will be highly
appreciated. Thanks in advance.
-- /Gong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/