On Wed, 02 Apr 2008 11:43:21 +0300 Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > On Wed, Apr 02 2008 at 6:37 +0300, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > > On Mon, 17 Mar 2008 22:34:22 +0100 > > Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > > >>> Look further down in the email, queue_bounce_to_mask() or whatever you > >>> would want to call it. As also written there, the PRINCIPLE is the same. > >>> And that is that exporting a to_allocator_mask() helper is a lot saner > >>> than exporting an allocator api tied to the queue. > >>> > >>> Can we get over this, please? > >> Ok it would have helped if you had explained why it is saner, but I > >> bow to your superior experience on block layer issues. > >> > >> The only open issue is right now if it isn't better to go back > >> for automatic bouncing for SCSI scan and the other users. Do you > >> have an opinion on that too? If you have one can you please convince > >> James of it too. > > > > There are other things that don't want the automatic bouncing; sg, st, > > and osst. > > > > Your patches remove unchecked_isa_dma in them and Boaz said that they > > are fine since they get bounced anyway, however, it's not correct. > > > > As Doug said in another thread (about your patch to change GFP_ATOMIC > > to GFP_KERNEL in sg), they try to avoid waiting for a long time and > > want an early failure (though they are not complete; can't avoid non > > unchecked_isa_dma bouncing) . > > > > We can change the bounce path in that way, but I think it's better if > > they can allocate memory that will not get bounced. > > I was looking in blk_queue_bounce (in mm/bounce.c) and have not seen any > case of q->bounce_gfp with __GFP_WAIT. Are you sure we are waiting for > the bounce buffers? It will take few more CPU cycles, but I don't see > where it will sleep. Hmm, q->bounce_gfp is GFP_NOIO or (GFP_NOIO | __GFP_DMA). And __blk_queue_bounce also allocates bio with GFP_NOIO. So the bounce path always use __GFP_WAIT. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html