DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: nd <nd@arm.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	nd <nd@arm.com>
Subject: Re: [dpdk-dev] Reader-Writer lock starvation issues
Date: Mon, 11 Jan 2021 13:05:02 +0000	[thread overview]
Message-ID: <DBAPR08MB58148339EC018B8E5D31333F98AB0@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <b3ca06a8-d105-950d-df82-97e4cf80be53@intel.com>

<snip>

> >
> >>
> >> The current version of rte_rwlock doesn't do what it says in the
> >> documentation.
> >> " The lock is used to protect data that allows multiple readers in
> >> parallel,  but only one writer. All readers are blocked until the writer is
> finished  writing."
> >>
> >> The problem is that the current implementation does not stop a a new
> >> reader from acquiring the lock while a writer is waiting.
> > Agree, essentially the arbitration is left to the hardware.
> >
> >>
> >> Writer:
> >>        repeat until x = __atomic_load(&counter) == 0;
> >>        __atomic_compare_exchange(&counter, &x, -1);
> >>
> >> Reader:
> >>        x = __atomic_load(&counter);
> >>        __atomic_compare_exchange(&counter, &x, x + 1);
> >>
> >>
> >> Fixing it likely would require an ABI change to add additional state.
> >>
> >> For more background on reader-writer locks see:
> >>
> >> https://www.cs.rochester.edu/research/synchronization/pseudocode/rw.h
> >> tm
> >> l
> >>
> >> The code in DPDK is actually effectively the same as the first
> >> example "Simple, non-scalable reader-preference lock"
> > I do not think the DPDK implementation has reader-preference. There is no
> code to control the arbitration between writers and readers. It is possible that if
> there are multiple writers the readers might be starved depending on how the
> hardware does the arbitration.
> >
> 
> As far as I can see, in current implementation:
> 
> When writer has the lock, both writers and readers needs to wait, and when
> writer releases reader or writer has chance to acquire the lock.
Yes, since reader or writer can acquire the lock (when writer releases), I do not think we can call the current implementation as 'reader-preference'.

> 
> When reader has the lock, other readers can acquire the lock and writers has to
> wait, and if readers keep coming it can cause writer starvation. Overall this
> doesn't look fair reader-writer lock ...
Agree

> 
> >>
> >> It looks like doing the right thing will require increasing the size
> >> of the rte_rwlock structure and cause an ABI breakage.
> >>
> >> I am running with an alternative which uses ticket locks to do:
> >>    "Simple, non-scalable writer-preference lock"
> > Does it provide good scalability?
> >
> >>
> >> My recommendation would be:
> >>
> >>   1. Fix documentation in rte_rwlock.h (and add release note) and put
> >> this in
> >> 20.02 and LTS.
> > Agree, the document is not clear on the arbitration.
> >
> >>   2. Add new rte_ticket_rwlock.h which provides the correct semantics.
> > Agree.
> >
> >>
> >> Comments?


  reply	other threads:[~2021-01-11 13:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 19:13 Stephen Hemminger
2021-01-08 21:27 ` Honnappa Nagarahalli
2021-01-11 11:52   ` Ferruh Yigit
2021-01-11 13:05     ` Honnappa Nagarahalli [this message]
2021-01-12  1:04 ` [dpdk-dev] [PATCH] eal/rwlock: add note about writer starvation Stephen Hemminger
2021-01-14 16:55   ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
2021-02-11 22:51     ` Thomas Monjalon
2021-02-12  0:21       ` Honnappa Nagarahalli
2021-05-12 19:10         ` Thomas Monjalon
2021-11-08 10:18           ` Thomas Monjalon

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=DBAPR08MB58148339EC018B8E5D31333F98AB0@DBAPR08MB5814.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=nd@arm.com \
    --cc=stephen@networkplumber.org \
    /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).