On Wed, Feb 05, 2014 at 06:08:37PM -0800, Muthu Kumar wrote: > > diff --git a/block/blk-core.c b/block/blk-core.c > > index c00e0bd..d3eb330 100644 > > --- a/block/blk-core.c > > +++ b/block/blk-core.c > > @@ -693,11 +693,20 @@ blk_init_queue_node(request_fn_proc *rfn, spinlock_t > > *lock, int node_id) > > if (!uninit_q) > > return NULL; > > > > + uninit_q->flush_rq = kzalloc(sizeof(struct request), GFP_KERNEL); > > > Shouldn't this be kzalloc_node()?
Probably. There's also various kinds of optimization potential like allocating one per hw_ctx or similar. But until we have a device that has high enough IOPS to matter and needs cache flushes I wouldn't worry about optimizing the flush path. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
