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 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
