msleep_spin is failed to waken up even after wakeup routine is invoked for the same.

Ian Lepore ian at freebsd.org
Wed Feb 19 14:42:48 UTC 2020


On Wed, 2020-02-19 at 14:13 +0530, Arpan Palit wrote:
> Hi,
> 
> I am facing one issue where wakeup rountine call is unable to waken up a
> msleep_spin routine call with a timeout value of 10 Seconds.
> 
> The real scenario is as follows: post a hardware command and sleep using
> msleep_spin routine till interrupt comes, After getting the interrupt waken
> up the sleeping process using wakeup_one/wakeup routine call. As there are
> more than 2048 command and 16 parallel threads are running,
> observed randomly *one or two of the posted command* is *timing out* for
> which the *interrupt has came and also wakeup routine is invoked *after
> getting the interrupt for the same command.
> 
> Note:
> *The issue is not seen when number of commands are less than 2048 with
> timeout of 10 seconds.
> *The issue can be seen with less number of commands also when timeout value
> 1 second.
> 
> Can anyone please provide me an optimized way to schedule the process or a
> better way to do the scheduling.
> 
> Thanks,
> Arpan Palit
> 

Is there any chance this is the classic "missed wakeup" scenario, where
the wakeup happens before the thread enters msleep_spin()?  That can
happen with code structured like

  enqueue_request(req);
  err = msleep_spin(req, etc);
  /* Handle done req or timeout */

and a fix is to structure the code using the same idiom required for
pthread_cond_wait() in userland, something like:

  req->doneflag = false;
  enqueue_request(req);
  while (!req->doneflag && err == 0)
      err = msleep_spin(req, etc);
  /* Handle done req or timeout */

and of course on the interrupt handler side you need something like

  /* lock mutex, do hardware stuff */
  req->doneflag = true;
  wakeup(req);
  /* unlock mutex */

-- Ian




More information about the freebsd-hackers mailing list