On Wed, Jan 10 2007, Vasily Tarasov wrote:
> Jens Axboe wrote:
> > On Tue, Jan 09 2007, Vasily Tarasov wrote:
> >
> >> Jens Axboe wrote:
> >>
> >>> On Tue, Jan 09 2007, Vasily Tarasov wrote:
> >>>
> >>>
> >>>> Jens Axboe wrote:
> >>>>
> >>>>
> >>>>> Tom, you are correct, the 'B' is a bounce and not a backmerge. Vasily,
> >>>>> you may want to look into your setup, bouncing is very harmful to io
> >>>>> performance.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> Hello again,
> >>>>
> >>>> My node has 4GB RAM and by default block queue limit
> >>>> is high memory boundary:
> >>>> blk_queue_bounce_limit(q, BLK_BOUNCE_HIGH);
> >>>> Driver doesn't set other bounce limit (like most drivers),
> >>>> so I have bounces.
> >>>>
> >>>> Seems, that all people with more then 1GB Memory
> >>>> should have such situation (except lucky beggars with "appropriate"
> >>>> drivers),
> >>>> am I right?
> >>>>
> >>>>
> >>> What driver do you use? By far the most common ones do support highmem
> >>> IO (like IDE/SATA/SCSI, etc).
> >>>
> >>>
> >>>
> >> My driver is NVIDIA Serial ATA.
> >>
> >
> > SATA/libata defaults to a full 32-bit dma mask, so it doesn't impose any
> > bounce restrictions. If the pci device has set a lower limit, then that
> > one applies of course. It's quite unusual to have bouncing hardware in
> > hardware from recent years, unless it's a buggy piece of hardware (or we
> > don't know how to drive upper limits, due to lack of documentation).
> >
> > You should look into why and who sets a lower mask for your device. Note
> > that the default limit is only active, until SCSI+libata configures a
> > queue and the slave config sets the limit again.
> Hello,
>
> I got the very interesting situation!
> blk_max_pfn = max_pfn = 1048576
> while SCSI/libata driver sets q->bounce_pfn = 1048575
> Thus I have a bunch of bounces.
> The main question for me now is why max_pfn = 1048576?
> I suppose that it should be equal to 1048575 on my 4GB RAM mashine:
> (4 x 1024 x 1024 x 1024) / (4 x 1024) = 1024 x 1024 = 1048576 - this is
> total number of page frames. But, max_pfn should be equal 1048576 - 1 =
> 1048575.
>
> What do you think?
It's because the device sets a 32-bit mask, which 0xffffffff. But even
with that one-off bug, you should basically never see bounces (only for
that single page at the top should you see a bounce). Ah, the bounce
trace is somewhat optimistic, this patch should fix that up.
diff --git a/mm/bounce.c b/mm/bounce.c
index e4b62d2..643efbe 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -237,6 +237,8 @@ static void __blk_queue_bounce(request_queue_t *q, struct
bio **bio_orig,
if (!bio)
return;
+ blk_add_trace_bio(q, *bio_orig, BLK_TA_BOUNCE);
+
/*
* at least one page was bounced, fill in possible non-highmem
* pages
@@ -291,8 +293,6 @@ void blk_queue_bounce(request_queue_t *q, struct bio
**bio_orig)
pool = isa_page_pool;
}
- blk_add_trace_bio(q, *bio_orig, BLK_TA_BOUNCE);
-
/*
* slow path
*/
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-btrace" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
