Re: How to map high memory for block io

[Jens Axboe]

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.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/