I have tried all sorts of stuff to make the swapper Ooops go away. I
have also completely reviewed all of the mm code, fs code, etc, etc.
And here's what I think I've determined to be invalid in my assumptions
about what's there:
1. Linux 2.2.15 and 2.3.99 do not support true Asynch IO. Asynch IO
allows a caller to post a very large number of requests, is not **NOT**
polled, and should be interrupt driven. The first request should "kick"
the queue head into the driver, then the driver should feed the next
buffer on the IO completion interrupt until the queue head is empty.
The way it's implemented in Linux requires that the bottom half ISR be
"polled" within wait_on_buffer() or some other function to initiate the
I/O and block until the IO returns -- how is this asynchronous I/O.
2. While the semantics appear to be Asynch, the interface is actually
synchronous in behavior -- you have to poll the drives after posting IO
to start the disks. The dependency on the lock_kernel() call on 2.2.15
guarantees that most callers will block when attempting multiple calls
to ll_rw_blk(), so there went the parallelism. I have noticed that if I
hold the kernel lock over the I/O (which is what is happening in
filemap.c and buffer.c) then the swapper does not crash the system.
This means that all I/O requests performed are really synchronous since
only one caller seems to be able to post at one time with crashing.
3. Feeding more than a handful of requests at one time to THE LINUX
BUFFER CACHE (forget NWFS code - I tried this with just Linux) will
cause the swapper process to Ooops and die. I implemented some very
simple code that just calls the buffer cache and tries to do asynch I/O
and "**KAPOW!!!*** , the system crashes. The code is attached.
Jeff Merkey
CEO, TRG
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:20 EST