Messages in this thread | | | Date | Mon, 30 Jan 2006 09:09:31 +0100 | From | Jens Axboe <> | Subject | Re: How to map high memory for block io |
| |
On Mon, Jan 30 2006, Pierre Ossman wrote: > Jens Axboe wrote: > > On Sat, Jan 28 2006, Pierre Ossman wrote: > > > >> Jens Axboe wrote: > >> > >>> On Fri, Jan 27 2006, Russell King wrote: > >>> > >>> > >>>> On Fri, Jan 27, 2006 at 10:58:59PM +0100, Pierre Ossman wrote: > >>>> > >>>> > >>>>> Test done here, few minutes ago. Added this to the wbsd driver in its > >>>>> kmap routine: > >>>>> > >>>>> if ((host->cur_sg->offset + host->cur_sg->length) > PAGE_SIZE) > >>>>> printk(KERN_DEBUG "wbsd: Big sg: %d, %d\n", > >>>>> host->cur_sg->offset, host->cur_sg->length); > >>>>> > >>>>> got: > >>>>> > >>>>> [17385.425389] wbsd: Big sg: 0, 8192 > >>>>> [17385.436849] wbsd: Big sg: 0, 7168 > >>>>> [17385.436859] wbsd: Big sg: 0, 7168 > >>>>> [17385.454029] wbsd: Big sg: 2560, 5632 > >>>>> [17385.454216] wbsd: Big sg: 2560, 5632 > >>>>> > >>>>> > >>>> Jens - what's going on? These look like invalid sg entries to me. > >>>> > >>>> If they are supposed to be like that, there will be additional problems > >>>> for block drivers ensuring cache coherency on PIO. > >>>> > >>>> > >>> No freaking idea, must be coming out of the pci dma mapping. The IOMMU > >>> doing funky stuff? How are these sg lists mapped? > >>> > >>> > >>> > >> This is an ISA (i.e. platform) device, so no PCI involved. There is also > >> no IOMMU on this system. > >> > >> As for the mapping there doesn't seem to be anything fancy about it > >> (this is Russell's territory so this is just my naive view of it). The > >> queue is set up in mmc_queue.c and the sg is mapped using > >> blk_rq_map_sg() in mmc_block.c. > >> > >> But if sg entries are not supposed to cross pages, then I guess that > >> means that any transfer is limited in size by PAGE_SIZE * > >> min(max_phys_seg, max_hw_seg), right? > >> > > > > Ah, you need to disable clustering to prevent that from happening! I was > > confused there for a while. > > > > > > And which is the lesser evil, highmem bounce buffers or disabling > clustering? I'd probably vote for the former since the MMC overhead can > be quite large.
Disabling clustering is by far the least expensive way to accomplish it.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |