Jens Axboe wrote: > 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 > */ Ok, then! :)
Actually I thought about such fix, but I supposed that even walking through pages on bio is considered as bounce... However I still don't understand, why max_pfn = 1048576, not 1048575. max_pfn is a number of the highest frame. So counting from zero it should be 0, 1, 2, .... _1048575_. Looking through the algorithm they use to get max_pfn, I suppose there is a bug. I'll send a patch to lkml and will keep you in CC. Thanks for the explanations and patch, I guess it'll be in the next kernel release. Vasily. - 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
