>Unfortunately an application has no control over allocation of its
>pages, so this basically makes raw IO useless right now with BIGMEM.
Again: it depends on what you have to do. If you want to use raw-io to
grab a mmaped framebuffer you can use raw-io fine also with bigmem
enabled.
If you instead need to do I/O from/to shm memory then you can't expect
raw-io to work correctly if you want to alloc up to 4giga of shm memory by
using the BIGMEM feature.
I sure agree that the rule is: "if your application is using raw-io and
you enabled CONFIG_BIGMEM, then you may expect your application to not
work anymore".
>What I plan to do is to allow ll_rw_block to support bounce-buffers
>transparently for devices which cannot safely access the high memory
>locations, but at the same time to let devices tell the kernel when it
What you meane exactly with bounce-buffers? I guess you don't mean to copy
the contents of every bigmem-buffer to another regular buffer and do I/O
with it. That would seems too slow to me (IMHO it would be faster to avoid
raw-io completly ;).
I just tried to put a wrapper in ll_rw_block to remap all b_data and
req->buffer in the fixmap area but then you have the problem that you can
have lots of buffer queued in only one request and so you should have lots
of kmap slots per-request (more kmap slots than NR_REQUEST). In my
experiment I had the usual current per-CPU R/W KMAP slots plus
NR_REQUEST-kmap slots and I was avoiding the merging of physically
contigous requests (and we can't do that in real-world). Then I was
remapping the req->bh->b_data and req->buffer of the request in the fixmap
area via a new kmap_request API. Then I had to change virt_to_bus to be
able to understand if the b_data was placed in the kmap_request area or
not (and if it was in the kmap area I had to return the real phisical
address and not the -PAGE_OFFSET one).
kmap_request was doing a _SMP_ TLB flush of the interested kmap (since you
don't know in which CPU the irq-completation handler will happen). Now we
don't have a way to issue a SMP invlpg tlb flush so I was using the
equally safe (but slower) smp_flush_all().
If you solve the request-coalesce problem with the number of kmap slots,
then flush_tlb_all() has to be reacalled also from the io-completation irq
(when you have to do the I/O on the next buffer queued in the current
request and you'll change req->buffer). And Linus seems not too much happy
to start an IPI-smp-invalidate irq from an irq handler. Anyway IMO it
should be completly safe because the kmap space is always shared by all
CPUs all the time, regardless of the current-context and we don't hold the
big kernel lock anymore while SMP-flushing the tlb.
BTW, I have two questions about the ll_rw_block/request internals.
1) can req->bh be null? IMHO no and it seems lots of code it's
wasting time checking for null there.
2) which is the difference between req->buffer and req->bh->b_data?
I can't see the difference. (if answer of (1) is yes, then when
I'll have understood (1) then probably I'll solve (2) too ;)
Thanks.
Andrea
-
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/