Jens Axboe wrote: > On Wed, Jan 10 2007, Vasily Tarasov wrote: > >> 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... >> > > It'll cost some CPU cycles of course, but nowhere near the scale of a > bounce. The bio is walked earlier anyway for calculating segments and > such, so it's not unusual or that heavy. > > >> 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. >> > > Yeah, it sounds like a bug in the max_pfn setup! > > Jens,
I just see that your patch above is still not in git and want to remind you about it, because you could forget about it. Thanks. - 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
