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: Mon, 19 May 2014 22:12:37 -0400	[thread overview]
Message-ID: <1203fd06e0a13df9c23d4a5e1ac1aad0@ladd.quanstro.net> (raw)
In-Reply-To: <CAFgOgC-=2z7JknR74-4geMwm2haV52FgtVA+U9wmOU11oTwrxQ@mail.gmail.com>

> It is an ordering, but I don't think it's a valid one: your ellipses
> suggest an unbounded execution time (given the context of the
> discussion). I don't think that's valid because the protocol can't
> possibly negotiate execution for more instructions than it has space
> for in its pipeline. Furthermore, the pipeline cannot possibly be

yes it is an unbounded set of instruction.  i am wondering if it isn't
possible for the same core to keep winning the MESI(F) arbitration.

i don't see tying µ-ops to cachelines.  load/store buffers i believe
is where cachelines come in to play.

> filled with LOCK-prefixed instructions because it also needs to
> schedule instruction loading, and it pipelines μops, not whole

i didn't read that in the arch guide.  where did you see this?

> instructions anyway. Furthermore, part of the execution cycle is
> decomposing an instruction into its μop parts. At some point, that
> processor is not going to be executing a LOCK instruction, it is going
> to be executing some other μop (like decoding the next LOCK-prefixed
> instruction it wants to execute). This won't be done with any
> synchronization. When this happens, other processors will execute
> their LOCK-prefixed instructions.

and this is an additional assumtion that i was trying to avoid.  i'm
interested if LOCK XADD is wait free in a theory.

> further instructions. Instruction load and decode stages are shared,

this is not always true.  and i think hints at the issue that it might be
inaccurate to generalize from your cpu to all MESI cpus.

i get a 126% difference executing lock xadd 1024*1024 times
with no branches using cores 4-7 of a xeon e3-1230.  i'm sure it would
be quite a bit more impressive if it were a bit easier to turn the timer
interrupt off.

i really wish i had a four package system to play with right now.  that
could yield some really fun numbers.  :-)

- erik

example run.  output core/cycles.
; 6.lxac
4 152880511
7 288660939
6 320991900
5 338755451




  reply	other threads:[~2014-05-20  2:12 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 [this message]
2014-05-20 14:47             ` Devon H. O'Dell
2014-05-20 15:41               ` erik quanstrom
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=1203fd06e0a13df9c23d4a5e1ac1aad0@ladd.quanstro.net \
    --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).