linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: chetan loke <loke.chetan@gmail.com>
To: Matthew Wilcox <willy@linux.intel.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-scsi@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: SCSI RAM driver ported to 3.3 kernel for file system and I/O testing
Date: Wed, 16 May 2012 15:54:06 -0400	[thread overview]
Message-ID: <CAAsGZS5tzf5-aciK2kCJCHn4oDTSAvN+=FQWzkH_3PzVm5m-iA@mail.gmail.com> (raw)
In-Reply-To: <20120516194332.GN22985@linux.intel.com>

On Wed, May 16, 2012 at 3:43 PM, Matthew Wilcox <willy@linux.intel.com> wrote:
> On Wed, May 16, 2012 at 03:37:56PM -0400, chetan loke wrote:
>> On Wed, May 16, 2012 at 3:35 PM, Matthew Wilcox <willy@linux.intel.com> wrote:
>> > On Wed, May 16, 2012 at 03:31:55PM -0400, chetan loke wrote:
>> >> > +               if (list_empty(&ram_device->commands))
>> >> > +                       wake_up_process(ram_device->thread);
>> >>
>> >> 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.
>>
>> Sorry, not able to follow. wait_even_interruptible will put kthread to
>> sleep. So how will it be already awake?
>
> Consider the following:
>
> CPU 0                   CPU 1
> ->queuecommand
> lock
> wakes kthread
> queues command 1
> unlock
>
> ->queuecommand
> lock
>                        kthread wakes
>                        lock
> queues command 2
> unlock
>                        dequeues command 1
>                        dequeues command 2
>                        unlock
>
>
> See?  No need to wake the kthread *if there's already something on the
> queue*, because you know it was already woken by whoever put the first
> command on the queue.

I thought that 'scsi_ram_device_thread' has a
'wait_event_interruptible' call if it sees that the list is empty. I
don't see that call that's why the confusion. Either queuecmd or
kthread will get the lock and so why keep the kthread spinning in that
while loop if there's nothing to do?

  reply	other threads:[~2012-05-16 19:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-16 17:07 SCSI RAM driver ported to 3.3 kernel for file system and I/O testing Tim Chen
2012-05-16 17:18 ` Joe Perches
2012-05-16 19:02   ` Tim Chen
2012-05-16 17:41 ` Bart Van Assche
2012-05-16 19:31 ` chetan loke
2012-05-16 19:35   ` Matthew Wilcox
2012-05-16 19:37     ` chetan loke
2012-05-16 19:43       ` Matthew Wilcox
2012-05-16 19:54         ` chetan loke [this message]
2012-05-16 20:22           ` Matthew Wilcox
2012-05-16 20:05   ` Tim Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAsGZS5tzf5-aciK2kCJCHn4oDTSAvN+=FQWzkH_3PzVm5m-iA@mail.gmail.com' \
    --to=loke.chetan@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=willy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).