From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: SCSI RAM driver ported to 3.3 kernel for file system and I/O testing Date: Wed, 16 May 2012 15:35:06 -0400 Message-ID: <20120516193506.GM22985@linux.intel.com> References: <1337188023.3796.130.camel@schen9-DESK> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Tim Chen , linux-fsdevel , linux-scsi@vger.kernel.org, linux-kernel , Andi Kleen To: chetan loke Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, May 16, 2012 at 03:31:55PM -0400, chetan loke wrote: > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (list_empty(&ram_device->commands)= ) > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wake_up_process(ram_d= evice->thread); >=20 > Didn't look in detail but if the queue is empty then why would you > want to wake up the kthread? What if you just wake_up after > list_add_tail below? If the list is non-empty, then the kthread has already been woken up and doesn't need to be woken again. > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 list_add_tail(&ram_cmnd->queue, &ram_= device->commands); > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock_irqrestore(shost->host_lo= ck, flags); > > + =A0 =A0 =A0 } else { > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 scsi_ram_execute_command(cmnd); > > + =A0 =A0 =A0 } >=20 >=20 > Chetan Loke