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