Messages in this thread | | | Date | Fri, 3 Sep 1999 12:50:35 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: CONFIG_BIGMEM and rawio |
| |
On Thu, 2 Sep 1999, Stephen C. Tweedie wrote:
>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/
| |