From: Stephen Hemminger <stephen@networkplumber.org>
To: Wojciech Panfil <wojciech.panfil@intel.com>
Cc: <bruce.richardson@intel.com>, <pallavi.kadam@intel.com>,
<dev@dpdk.org>, <jacek.kalwas@intel.com>,
<konrad.sztyber@intel.com>, <dmitry.kozliuk@gmail.com>,
<roretzla@linux.microsoft.com>
Subject: Re: [PATCH] eal/alarm_cancel: Fix thread starvation
Date: Sat, 28 Sep 2024 09:40:53 -0700 [thread overview]
Message-ID: <20240928094053.47f3c72c@hermes.local> (raw)
In-Reply-To: <20240925194206.106825-1-wojciech.panfil@intel.com>
On Wed, 25 Sep 2024 21:42:06 +0200
Wojciech Panfil <wojciech.panfil@intel.com> wrote:
> Issue:
> Two threads:
>
> - A, executing rte_eal_alarm_cancel,
> - B, executing eal_alarm_callback.
>
> Such case can cause starvation of thread B. Please see that there is a
> small time window between lock and unlock in thread A, so thread B must
> be switched to within a very small time window, so that it can obtain
> the lock.
>
> Solution to this problem is use sched_yield(), which puts current thread
> (A) at the end of thread execution priority queue and allows thread B to
> execute.
>
> The issue can be observed e.g. on hot-pluggable device detach path.
> On such path, rte_alarm can used to check if DPDK has completed
> the detachment. Waiting for completion, rte_eal_alarm_cancel
> is called, while another thread periodically calls eal_alarm_callback
> causing the issue to occur.
>
> Signed-off-by: Wojciech Panfil <wojciech.panfil@intel.com>
It would be good to get test for this in the DPDK functional test.
See: https://patchwork.dpdk.org/project/dpdk/patch/20240809152540.9568-4-stephen@networkplumber.org/
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
next prev parent reply other threads:[~2024-09-28 16:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 19:42 [PATCH] eal/alarm_cancel: Fix thread starvation Wojciech Panfil
2024-09-28 16:40 ` Stephen Hemminger [this message]
2024-10-04 12:00 ` David Marchand
-- strict thread matches above, loose matches on Subject: below --
2024-09-18 11:39 Wojciech Panfil
2024-09-18 16:06 ` Stephen Hemminger
2024-09-18 7:02 Wojciech Panfil
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=20240928094053.47f3c72c@hermes.local \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=jacek.kalwas@intel.com \
--cc=konrad.sztyber@intel.com \
--cc=pallavi.kadam@intel.com \
--cc=roretzla@linux.microsoft.com \
--cc=wojciech.panfil@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.