9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] waitfree
Date: Tue, 20 May 2014 11:41:29 -0400	[thread overview]
Message-ID: <3d8d9b061e102356bda61520e1682072@ivey> (raw)
In-Reply-To: <CAFgOgC-+doRSYxihs02gCR--_cPKnvMyEswLfyEZsEsYVd90MA@mail.gmail.com>

> Dunno what to say. I'm not trying this on Plan 9, and I can't
> reproduce your results on an i7 or an e5-2690. I'm certainly not
> claiming that all pipelines, processors, and caches are equal, but
> I've simply never seen this behavior. I also can't think of an
> application in which one would want to execute a million consecutive
> LOCK-prefixed instructions. Perhaps I just lack imagination.

the original question was, are locked instructions wait free.  the
purpose was to see if there could be more than a few percent
variation, and it appears there can be.

i think in modern intel microarches this question boils down to,
can a given cpu thread in an arbitrary topology transition an
arbitrary cacheline from an arbitrary state to state E in a bounded
number of QPI cycles.

of course this reformulation isn't particular helpful, at least to me,
given the vagueness in the descriptions i've seen.

this is practically important because if there is a dogpile lock or
bit of shared memory in the system, then a particular cpu may
end up waiting quite a long time to acquire the lock.  it may
even get starved out for a bit, perhaps with a subset of other cpus
"batting around" more than once.

this would be hidden waiting behavior that might lead to surprising
(lack of) performance.

i would say this vaguery could impede worst-cast analysis for safety
critical systems, but you'd be pretty adventursome, to say the least,
to use a processor with SMM in such a system.

- erik



  reply	other threads:[~2014-05-20 15:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19 17:34 erik quanstrom
2014-05-19 19:49 ` Devon H. O'Dell
2014-05-19 20:21   ` erik quanstrom
2014-05-19 21:01     ` Devon H. O'Dell
2014-05-19 22:05       ` erik quanstrom
2014-05-19 22:14         ` ron minnich
2014-05-19 22:18           ` erik quanstrom
2014-05-20  1:10         ` Devon H. O'Dell
2014-05-20  2:12           ` erik quanstrom
2014-05-20 14:47             ` Devon H. O'Dell
2014-05-20 15:41               ` erik quanstrom [this message]
2014-05-20 19:14                 ` Devon H. O'Dell
2014-05-20 19:30                   ` erik quanstrom
2014-05-20 20:32                     ` Devon H. O'Dell

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=3d8d9b061e102356bda61520e1682072@ivey \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /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).