From: Doug Ledford <dledford@redhat.com>
To: "Håkon Bugge" <Haakon.Bugge@oracle.com>,
"Don Hiatt" <don.hiatt@intel.com>,
"Dasaratharaman Chandramouli"
<dasaratharaman.chandramouli@intel.com>,
"Ira Weiny" <ira.weiny@intel.com>,
"Sean Hefty" <sean.hefty@intel.com>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] IB/core: Make ib_mad_client_id atomic
Date: Thu, 19 Apr 2018 23:55:55 -0400 [thread overview]
Message-ID: <1524196555.11756.30.camel@redhat.com> (raw)
In-Reply-To: <20180418142450.15581-1-Haakon.Bugge@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
> Two kernel threads may get the same value for agent.hi_tid, if the
> agents are registered for different ports. As of now, this works, as
> the agent list is per port.
>
> It is however confusing and not future robust. Hence, making it
> atomic.
>
People sometimes underestimate the performance penalty of atomic ops.
Every atomic op is the equivalent of a spin_lock/spin_unlock pair. This
is why two atomics are worse than taking a spin_lock, doing what you
have to do, and releasing the spin_lock. Is this really what you want
for a "confusing, let's make it robust" issue?
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-04-20 3:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 14:24 [PATCH] IB/core: Make ib_mad_client_id atomic Håkon Bugge
2018-04-18 18:51 ` Weiny, Ira
2018-04-19 2:59 ` Yanjun Zhu
2018-04-20 3:55 ` Doug Ledford [this message]
2018-04-20 15:34 ` Jason Gunthorpe
2018-04-23 14:19 ` Håkon Bugge
2018-04-23 19:16 ` jackm
2018-04-23 19:16 ` jackm
2018-04-26 16:06 ` Håkon Bugge
2018-04-26 18:32 ` jackm
[not found] ` <9fdd3ec4-ee91-5442-e753-25d2ecd27ea9@xsintricity.com>
[not found] ` <A58D5192-06E7-46A3-869C-273E9A2BC128@oracle.com>
2018-04-27 19:08 ` Doug Ledford
2018-04-30 11:50 ` Håkon Bugge
2018-04-30 14:49 ` Jason Gunthorpe
2018-04-30 17:10 ` Doug Ledford
2018-04-30 17:49 ` Weiny, Ira
2018-04-30 23:01 ` Jason Gunthorpe
2018-05-01 4:38 ` jackm
2018-05-01 6:40 ` Håkon Bugge
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=1524196555.11756.30.camel@redhat.com \
--to=dledford@redhat.com \
--cc=Haakon.Bugge@oracle.com \
--cc=dasaratharaman.chandramouli@intel.com \
--cc=don.hiatt@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sean.hefty@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.