On Tue, 23 May 2000, Albert D. Cahalan wrote:
>Jesse Pollard writes:
>> On Tue, 23 May 2000, Andrew McNabb wrote:
>
>>> So what do you do if you need to interrupt the process and don't care
>>> whether or not it's waiting on a disk? I've had problems where I had
>>> to reboot a UNIX box because a ufsdump or an mt or something got a lock
>>> on a tape device and hung. There should probably be a way to kick a
>>> process out of uninturruptable sleep, shouldn't there?
>>
>> Yes and No - To do this requires the ability to perform a "rundown" of
>> all possible I/O to the memory/buffer that is waiting for completion.
>...
>> It depends, in part, on the ability to abort a controller+device
>> in the middle of I/O, determine if the I/O is part of the desired
>> "rundown" or resume the transaction. This is a serious problem
>
>No, the process could be killed. Depending on the hardware, one
>might get stuck with a bit of garbage to be collected later.
>Basically you just free all unrelated resources, then declare
>the process to be dead and buried.
>
>Note: using "device" to mean something physical
>
>So you have 1000 pages of memory, with 20 being actively written
>to by a device doing DMA. Fine, free the other 980 pages.
>The device doesn't even know what a PID is, so reclaim that too.
>Devices don't know about file descripters, so free those. Etc.
This is called a memory leak... And you can crash some systems
with it, especially those with devices with limited address DMA.
It is also larger than 20 pages --- the buffer headers have to be
saved, the dma request descriptions have to be saved, and other
lists needed so that the driver can release the memory when the
DMA does complete (and figure out what to do for network devices...).
You also get a problem when the DMA completes - what process is it
that gets a wakeup (though this should be able to be handled).
IO rundown is not simple. The entire kernel IO has to know how to do it,
and then the kernel memory allocator has to deal with the horrendous
fragmentation that can occur. It is possible to do, just not simple.
It requires keeping a copy of all dma requests so that if a rundown
is requested, each driver (or at least all that have a request for
a process...) can determine what memory is involved. This gets
messy for those drivers/devices with scatter/gather capability.
Theres an additional overhead of managing an additional list for
each driver (a "busy" list, so that the driver can release the memory
after the DMA completes), and an additional list for each process (which
drivers might have "busy" requests... though this one might already exist). It
has been a while since I've worked with systems that have the IO rundown
capability (VAX VMS was the last one..).
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@cats-chateau.netAny opinions expressed are solely my own.
- 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 : Wed May 31 2000 - 21:00:11 EST