On Fri, 3 Sep 1999 16:29:02 +0200 (CEST), Andrea Arcangeli
<andrea@suse.de> said:
>> You only actually need the mapping when you copy the buffer. The IO
>> then takes place in normal kernel va space.
> Of course if you replace the buffer with a copy of it, then you can live
> with only the two R/W per-CPU kmaps.
Not quite: if you do that underneath ll_rw_block, then the completion
interrupt needs to be able to do the final copy on a read request, and
that needs a separate kmap in case the interrupt occurred in the middle
of a foreground process using its own kmap.
> But what I was talking about was to preserve zero-copy to do real I/O on
> bigmem pages by kmapping all the buffers as far as they was entering the
> ll_rw_block layer without copying them.
Yes, and that is exactly what we'll need in the long term. We will
still need bounce buffers for some devices, but a lot of devices will be
able to live without them.
> To use kmap from irq handlers with irq enabled we'll waste 31 mbyte of
> virtual memory space.
If the entire page cache can now live outside of the va space, that is
still a *large* net increase in the usable kernel va!
> It would be nice to do a cleanup of the interface and to drop req->buffer.
> The fixage of the drivers (at least in theory) should be trivial.
Yep.
One last thing, Andrea: are you planning on fixing kswapd for bigmem?
Right now 2.3.16's kswapd doesn't check what kinds of memory are free.
If we have a lot of free high-memory pages and no low-memory space free,
then kswapd will stand idly by while the network layers are starved of
memory. That's a _bad_ bug in the bigmem as it stands. I'll fix this
next week if you aren't already working on it.
--Stephen
-
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/