Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #111126 > unrolled thread
| Started by | Robert Finch <robfi680@gmail.com> |
|---|---|
| First post | 2025-03-13 00:50 -0400 |
| Last post | 2025-03-17 17:33 -0400 |
| Articles | 20 on this page of 211 — 12 participants |
Back to article view | Back to comp.arch
MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 00:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:34 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 13:49 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 15:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 20:46 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:39 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 17:00 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:27 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:28 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 21:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 23:52 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:52 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 15:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 17:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 18:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-14 22:10 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 17:46 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-15 16:46 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 22:28 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-16 17:35 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-16 22:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 13:38 +0000
Re: MSI interrupts Michael S <already5chosen@yahoo.com> - 2025-03-17 16:11 +0200
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 11:23 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-17 14:33 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:14 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-18 14:51 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 17:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 23:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:49 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:54 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:03 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-19 14:03 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:59 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:44 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:41 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 20:25 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 21:55 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 12:37 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 13:59 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:49 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:12 -0700
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 19:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:02 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:05 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:17 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:32 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:36 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-24 14:02 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 19:09 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:29 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:43 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 11:48 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:29 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 13:28 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 13:53 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 20:33 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:47 +0000
Re: MSI interrupts Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-27 10:55 +0100
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 20:31 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:08 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:20 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:38 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:21 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:23 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:29 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:53 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 13:46 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:09 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:11 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:50 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 01:53 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 01:26 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 00:07 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 12:23 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 15:01 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:10 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 16:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 20:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 18:49 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:33 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 22:58 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:40 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:42 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 09:17 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 13:42 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 17:09 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 01:00 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 00:56 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 09:55 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 14:57 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-26 13:22 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-03 22:19 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:21 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:41 -0400
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:16 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 21:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:22 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 23:48 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 00:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 12:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 17:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 14:27 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 19:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 01:01 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:47 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 22:02 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:14 -0700
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-29 10:31 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:56 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 21:52 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:58 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:09 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:10 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 21:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 15:24 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-28 11:41 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 09:51 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 14:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 15:23 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:58 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 22:04 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 10:54 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:31 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-28 14:40 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-30 16:34 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 03:33 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-31 01:30 -0400
Software synchronization (was: Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 14:42 +0000
Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-03-31 15:28 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-01 16:44 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 15:31 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 12:49 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 20:01 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 13:17 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 22:04 +0000
Re: Threads (was Re: MSI interrupts) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-02 06:25 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-02 13:04 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-03 16:45 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 15:00 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 17:16 +0000
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 17:24 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-04 01:44 +0000
Centronics (was Re: Threads (was Re: MSI interrupts)) George Neuner <gneuner2@comcast.net> - 2025-04-03 22:22 -0400
Re: Centronics (was Re: Threads (was Re: MSI interrupts)) scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 02:29 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-03 01:38 -0400
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 12:15 +0000
Re: Threads (was Re: MSI interrupts) Robert Swindells <rjs@fdy2.co.uk> - 2025-04-04 10:41 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-04 23:10 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-01 10:07 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-01 17:39 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 23:28 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:50 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 22:28 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-23 12:16 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-23 16:48 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 11:55 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 18:56 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-23 17:48 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:39 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-20 12:03 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:52 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-19 13:07 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 15:47 -0400
Re: MSI interrupts - Instructions Robert Finch <robfi680@gmail.com> - 2025-03-26 06:56 -0400
Re: MSI interrupts - Instructions EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-26 10:33 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 22:49 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 20:39 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 01:22 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 23:22 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:56 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 21:49 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 01:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 18:51 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 19:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-19 11:20 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 16:00 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 13:27 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:17 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 10:12 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 19:06 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:33 -0400
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 23:33 +0000 |
| Message-ID | <vrvegn$fv9$2@reader1.panix.com> |
| In reply to | #111316 |
In article <jwvjz8coho7.fsf-monnier+comp.arch@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >Dan Cross [2025-03-25 22:19:07] wrote: >> From what I gather, you've said to just eschew the atomic event >> stuff and build a traditional lock using those primitives. But >> you have also said that a traditional lock can be silently >> unlocked if the thread holding it (which, apparently, is an >> abstraction known to hardware) is preempted. It will be like >> the lock had never been acquired. > >Here's the misunderstanding: the lock that can be silently taken away >is the lock implemented in the CPU to run an ATOMIC sequence, not the >lock implemented as a data-structure on top of it: once you've run >(atomically) your `lock_acquire`, of course that lock is yours. The CPU >doesn't even know that this data-structure is a lock and has no >way to steal it. I hope you are right, and I'd like Mitch to confirm. Even so, I don't see the point of the proposed atomic framework. It seems to have no significant advantage over a more traditional scheme; CAS, LL-SC, whatever seem more general and less intertwined with primitives that the hardware has no real business injecting itself into (like threads). - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-25 22:58 -0400 |
| Message-ID | <jwv34f0o75h.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111319 |
> Even so, I don't see the point of the proposed atomic framework.
> It seems to have no significant advantage over a more
> traditional scheme; CAS, LL-SC, whatever seem more general and
> less intertwined with primitives that the hardware has no real
> business injecting itself into (like threads).
AFAICT it's somewhat similar to ARM's LL/SC (which can also cover some
number of cache lines) except that it takes care of looping for you: if
the final store fails because of interference My 66000 will "simply" abort
the whole operation (reusing the speculation hardware) and start over,
instead of having to write an explicit loop.
Without actual hardware and software to try it's hard to assess how well
it's going to work, but the design sounds good: it should lead to more
compact code than LL/SC, be more general/friendly to lock-free coding
than T&S/C&S, and also compared to LL/SC it should behave better under
high contention because it is careful to guarantee overall forward
progress (in case of conflict between two cores, at least one of them
can finish successfully).
IIRC there's also some kind of mechanism to retry more cleverly, i.e. so
that when N cores are in conflicts, not only one of them succeeds, but
the N-1 remaining cores have a fighting chance of avoiding bumping into
each other next time around. I don't know the details, tho, and IIUC
this is not automatic: some relevant info is provided but it's up to the
code to do something useful with it.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-26 04:40 +0000 |
| Message-ID | <vs00gb$f3$1@reader1.panix.com> |
| In reply to | #111324 |
In article <jwv34f0o75h.fsf-monnier+comp.arch@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Even so, I don't see the point of the proposed atomic framework. >> It seems to have no significant advantage over a more >> traditional scheme; CAS, LL-SC, whatever seem more general and >> less intertwined with primitives that the hardware has no real >> business injecting itself into (like threads). > >AFAICT it's somewhat similar to ARM's LL/SC (which can also cover some >number of cache lines) except that it takes care of looping for you: if >the final store fails because of interference My 66000 will "simply" abort >the whole operation (reusing the speculation hardware) and start over, >instead of having to write an explicit loop. > >Without actual hardware and software to try it's hard to assess how well >it's going to work, but the design sounds good: it should lead to more >compact code than LL/SC, be more general/friendly to lock-free coding >than T&S/C&S, and also compared to LL/SC it should behave better under >high contention because it is careful to guarantee overall forward >progress (in case of conflict between two cores, at least one of them >can finish successfully). Ah, thanks, Stefan. That makes more sense. Perhaps some day there will be hardware and systems software and we can see how it actually works out in practice. I remain skeptical given the example code that was posted, and it appears that the claims are still just that: claims. Regardless, if anyone has the sort of track record to demonstrate that they can pull it off on the hardware side, Alsup certainly does, so maybe my skepticism is overly pessimistic and unwarranted. - Dan C. >IIRC there's also some kind of mechanism to retry more cleverly, i.e. so >that when N cores are in conflicts, not only one of them succeeds, but >the N-1 remaining cores have a fighting chance of avoiding bumping into >each other next time around. I don't know the details, tho, and IIUC >this is not automatic: some relevant info is provided but it's up to the >code to do something useful with it.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-26 19:42 +0000 |
| Message-ID | <6b029419f71cccffa4d6053bc19410f4@www.novabbs.org> |
| In reply to | #111324 |
On Wed, 26 Mar 2025 2:58:08 +0000, Stefan Monnier wrote:
>> Even so, I don't see the point of the proposed atomic framework.
>> It seems to have no significant advantage over a more
>> traditional scheme; CAS, LL-SC, whatever seem more general and
>> less intertwined with primitives that the hardware has no real
>> business injecting itself into (like threads).
>
> AFAICT it's somewhat similar to ARM's LL/SC (which can also cover some
> number of cache lines) except that it takes care of looping for you: if
> the final store fails because of interference My 66000 will "simply"
> abort
> the whole operation (reusing the speculation hardware) and start over,
> instead of having to write an explicit loop.
>
> Without actual hardware and software to try it's hard to assess how well
> it's going to work, but the design sounds good: it should lead to more
> compact code than LL/SC, be more general/friendly to lock-free coding
> than T&S/C&S, and also compared to LL/SC it should behave better under
> high contention because it is careful to guarantee overall forward
> progress (in case of conflict between two cores, at least one of them
> can finish successfully).
>
> IIRC there's also some kind of mechanism to retry more cleverly, i.e. so
> that when N cores are in conflicts, not only one of them succeeds, but
> the N-1 remaining cores have a fighting chance of avoiding bumping into
> each other next time around. I don't know the details, tho, and IIUC
> this is not automatic: some relevant info is provided but it's up to the
> code to do something useful with it.
ESM operates in 3 modes {optimistic, Greedy, Methodological}
In the optimistic mode, core tries to execute the instructions as
if there were no ATOMIC activities and if it succeeds, then these
ATOMIC instructions took no more time than if they were not ATOMIC
at all.
Greedy:: if there is a failure in optimistic mode, the core switches
to Greedy Mode, applies sequential consistency to memory accesses,
and is allowed to NaK lower priority SNOOPs if it has decoded all
the way to the esmLOCKstore(). A second SNOOP to an already SNOOPed
cache line fails the event and switches mode to methodological.
Methodological: When Greedy fails, core switches to Methodological.
The addresses of the participating lines are bundled up into a
message to the system arbitor, who uses a TLB-like structure to
GRANT exclusive access to up to 8 cache lines, returning a message
to core. That message contains a count of cores ahead of this one
in contention. SW can use count to proactively decrease interference.
At the end of the event (both success and fail) the same message
is sent to the arbitor to remove these lines from its grant table.
Grants are en-massé and deGrants are en-massé.
After any success, ESM reverts to Optimistic. SW does not see these
modes in operation.
After any context-switch ESM reverts to Optimistic.
When SW arrives at a fail point, SW can read the WHY register (16-bits)
positive numbers are a count of events in front of this one, negative
numbers are an enumeration of spurious failures, zero is success.
>
> Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-27 09:17 -0400 |
| Message-ID | <jwv5xjulili.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111333 |
> ESM operates in 3 modes {optimistic, Greedy, Methodological}
[...]
Sounds fancy, but it also makes me worry about the complexity of
verifying&testing correctness (of the implementation).
Stefan
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-27 13:42 +0000 |
| Message-ID | <ABcFP.1764331$TBhc.466619@fx16.iad> |
| In reply to | #111343 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> ESM operates in 3 modes {optimistic, Greedy, Methodological}
>[...]
>
>Sounds fancy, but it also makes me worry about the complexity of
>verifying&testing correctness (of the implementation).
Agreed. A lot of complexity for an unknown performance impact.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-25 17:09 -0700 |
| Message-ID | <vrvgjg$enmd$1@dont-email.me> |
| In reply to | #111316 |
On 3/25/2025 3:49 PM, Stefan Monnier wrote: > Dan Cross [2025-03-25 22:19:07] wrote: >> From what I gather, you've said to just eschew the atomic event >> stuff and build a traditional lock using those primitives. But >> you have also said that a traditional lock can be silently >> unlocked if the thread holding it (which, apparently, is an >> abstraction known to hardware) is preempted. It will be like >> the lock had never been acquired. > > Here's the misunderstanding: the lock that can be silently taken away > is the lock implemented in the CPU to run an ATOMIC sequence, not the > lock implemented as a data-structure on top of it: once you've run > (atomically) your `lock_acquire`, of course that lock is yours. Indeed. For some reason it kind of seems like Dan just might be a little confused about this point? > The CPU > doesn't even know that this data-structure is a lock and has no > way to steal it.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-26 01:00 +0000 |
| Message-ID | <77bb0ceb5cc9778b361831bc86f5d920@www.novabbs.org> |
| In reply to | #111316 |
On Tue, 25 Mar 2025 22:49:29 +0000, Stefan Monnier wrote:
> Dan Cross [2025-03-25 22:19:07] wrote:
>> From what I gather, you've said to just eschew the atomic event
>> stuff and build a traditional lock using those primitives. But
>> you have also said that a traditional lock can be silently
>> unlocked if the thread holding it (which, apparently, is an
>> abstraction known to hardware) is preempted. It will be like
>> the lock had never been acquired.
>
> Here's the misunderstanding: the lock that can be silently taken away
> is the lock implemented in the CPU to run an ATOMIC sequence, not the
> lock implemented as a data-structure on top of it: once you've run
> (atomically) your `lock_acquire`, of course that lock is yours. The CPU
> doesn't even know that this data-structure is a lock and has no
> way to steal it.
You are getting at the "why". In Compare-Swap atomic sequences with
your typical ISA, the HW does not see the initial LD (of the memory
participating in the compare-swap instruction) as locked. In the LL-
SC version, HW does have that tidbit of information.
With that information, the event is secured both by data and by
address, preventing the ABA problem {At least in ESM}.
>
>
> Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-26 00:56 +0000 |
| Message-ID | <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org> |
| In reply to | #111314 |
On Tue, 25 Mar 2025 22:19:07 +0000, Dan Cross wrote: > In article <e4ecfb53ef4f33f10b6d2548d5930159@www.novabbs.org>, > MitchAlsup1 <mitchalsup@aol.com> wrote: > >>> Your stuff sounds fine for getting into the critsec; but it >>> doesn't help you once you're in it, and it seems like it may >>> hurt you if some higher-priority thing comes along and yanks >>> your lock out from under you. >> >>I conceded that point at least 2 days ago. > > Ok, now we're back to the question then: what purpose does it > serve? You (well Chris) can write critical sections where a low priority holder can give way to the higher priority requestor such that the low priority holder reverts back to before it entered CS, and does not see the lock being stolen. For the sizes of CSs this covers--it prevent priority inversion. > It doesn't seem like it can be usefully applied to > anything other than building traditional mutexes based on spin > locks, and even then I'm not sure if that's correct (see above). And here I thought you had an imagination ..... > - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-26 04:08 +0000 |
| Message-ID | <vrvukp$n29$1@reader1.panix.com> |
| In reply to | #111322 |
In article <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Tue, 25 Mar 2025 22:19:07 +0000, Dan Cross wrote:
>
>> In article <e4ecfb53ef4f33f10b6d2548d5930159@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>
>>>> Your stuff sounds fine for getting into the critsec; but it
>>>> doesn't help you once you're in it, and it seems like it may
>>>> hurt you if some higher-priority thing comes along and yanks
>>>> your lock out from under you.
>>>
>>>I conceded that point at least 2 days ago.
>>
>> Ok, now we're back to the question then: what purpose does it
>> serve?
>
>You (well Chris) can write critical sections where a low priority
>holder can give way to the higher priority requestor such that
>the low priority holder reverts back to before it entered CS,
>and does not see the lock being stolen.
You still have not defined what you mean by, "the lock being
stolen."
Tell you what. Earlier, you posted some code for a critical
section that inserts a node into a linked list. That code is
written in terms of some primitives (presumably intrinsics,
though you call them macros); `esmLOCKload`, `esmLOCKprefetch`,
`esmINTERFERENCE` and `esmLOCKstore`. Here's that code, slightly
reformatted:
// Removes the element `from` from a doubly linked list, and
// inserts it into a (possibly different) doubly linked list,
// after the element pointed to be `to`.
// Assumes <stdbool.h>
bool
MoveElement(Element *from, Element *to)
{
assert(from != NULL);
assert(to != NULL);
Element *from_next = esmLOCKload(from->next);
Element *from_prev = esmLOCKload(from->prev);
Element *to_next = esmLOCKload(to->next);
esmLOCKprefetch(from_next);
esmLOCKprefetch(from_prev);
esmLOCKprefetch(to_next);
if (!esmINTERFERENCE()) {
// Unlink the "from" node from its list.
from_prev->next = from_next; // XXX: `from_prev` may be nil?
from_next->prev = from_prev; // XXX: `from_next` may be nil?
// Insert the node after "to".
to->next = from;
to_next->prev = from; // XXX: `to_net` may be nil?
from->prev = to;
esmLOCKstore(from->next, to_next);
return true;
}
return false;
}
Leaving aside the unchecked boundary conditions I highlighted
above, there are other questions that this raises. You
mentioned that the ESM stuff can use up to 8 cache lines in a
single atomic "event"; let's count how many this code may
encounter:
1. `from` may point to a cache line
2. `to` may point to a different cache line.
3. Does your architecture use a stack? What sort of alignment
criteria do you impose? At first blush, it seems to me that
the pointers `from_next`, `from_prev`, and `to_next` could be
on the stack and if so, will be on at least one cache line,
and possibly 2, if the call frame for `MoveElement` spans
more than one. Of course, it's impossible to say when this
is compiled, but maybe you require that the stack is always
aligned to a cache line boundary or something. Or maybe
these are all in registers and it's fine.
4. Depending on the size and alignment criteria of the the
`Element` structure and the placement of the `next` and
`prev` elements in the struct (unknowable from this example),
`to->next` may be on another cache line.
5. Similarly, `from->next`
6. And `from->prev`
7. And `from_prev->next`
8. And `from_next->prev`
9. And `to_next->prev`.
So potentially this code _could_ touch 9 or 10 cache lines, more
than you said are supported for a single atomic event. What
happens in that case? Does the code just always return false?
The programmer best make sure the optimizer is keeping those
temporary pointers off the stack; good luck with a debug build.
Anyway, let's assume that's not the case, and we don't hit the
pathological case with cache lines, and we're not dealing with
edge cases at the front or end of the lists (so various next or
prev pointers are not NULL). Why don't I try to explain what I
think this code is doing, and you tell me whether I'm right or
wrong.
If I understand this correctly, the `esmLOCKload`s are simply
loads, but they make sure that the compiler emits instructions
that tie into your atomic support framework. Earlier you wrote,
"esmINTERFERENCE is a query on the state of th event and whether
a 2nd party has performed a memory action that kills the event."
Ok, I take this to mean _at the time of the store_, which
appears later in the program. If it were simply a query at the
time it was written in the code, then it seems like it opens a
TOCTOU bug (what if something interfers after the check, but
before the the locked store at the end?). Or perhaps it signals
to the architecture that this is the point to which the
processor should rollback, if anything subsequently fails; sort
of a `setjmp` kind of thing that conceptually returns twice.
Assuming nothing has poisoned the event, the various pointer
stores inside the conditional are conditionally performed; the
`esmLOCKstore` to `from->next` commits the event, at which
point all side effects are exposed and durable.
Is that correct? Let's suppose that it is.
But later you wrote,
>So, if you want the property whereby the lock disappears on any
>control transfer out of the event {exception, interrupt, SVC, SVR, ...};
>then you want to use my ATOMIC stuff; otherwise, you can use the
>normal ATOMIC primitives everyone and his brother provide.
Well, what precisely do you mean here when you say, "if you want
the property whereby the lock disappears on any control transfer
out of the event"?
What I _hope_ you mean is that if you transfer "out of the
event" before the `esmLOCKstore` then anything that's been done
since the "event" started is rolled back, but NOT if control
transfer happens _after_ the `esmLOCKstore`. If THAT were the
case, then this entire mechanism is useless.
Perhaps you would clarify?
But for the time being, let's assume that `esmLOCKstore` is
conceptually a commit that ends the atomic event, and the store
is durable and observable after that. Let's see if we can
construct a simple spinlock from these primitives.
typedef struct Spinlock Spinlock;
struct Spinlock {
uint32_t lock;
};
uint32_t
xcas(volatile Spinlock *lk, uint32_t expected, uint32_t val)
{
uint32_t v = esmLOCKload(&lk->lock);
if (v == expected && !esmINTERFERENCE()) {
esmLOCKstore(&lk->lock, val)
}
return v;
}
void
spin_acquire(volatile Spinlock *lk)
{
splhi();
while (xcas(lk, 0, 1) != 0)
relax(); // Spin loop intrinsic.
}
void
spin_release(volatile Spinlock *lk)
{
xcas(lk, 1, 0);
// Maybe we should `spllo` here, maybe not. Either choice
// reflects lots of assumptions about whether or not we might
// take and hold multiple locks concurrently, etc.
spllo();
}
Does this seem correct? It is not immediately clear to me
whether `esmINTERFERENCE` is actually needed here, but
avoiding the store seemed fine. One could imagine shorting
`xcas` to simply:
uint32_t
xcas(volatile Spinlock *lk, uint32_t expected, uint32_t val)
{
uint32_t v = esmLOCKload(&lk->lock);
if (v == expected) esmLOCKstore(&lk->lock, val);
return v;
}
or perhaps:
uint32_t
xswap(volatile Spinlock *lk, uint32_t val)
{
uint32_t v = esmLOCKload(&lk->lock);
esmLOCKstore(&lk->lock, val);
return v;
}
But that all depends on the specifics of the atomics.
>For the sizes of CSs this covers--it prevent priority inversion.
Except you've admitted that this is not a general solution, as
it cannot "cover" arbitrary software-defined critical sections:
the window isn't big enough and we've seen how even a fairly
small problem may exceed the number of cache lines supported by
one of these events.
So I have to implement solutions to priority inversion problems
outside of your scheme anyway. Clearly, whatever mechanism is
chosen to do so is, by definition, also general enough to cover
the use cases for which your atomic scheme is best suited.
Plus, as you stated, this whole thing is wrapped up in notions
of threads and priorities that appear to try and subsume some
functionality from the OS, whether it's a good fit for a
particular OS's expectations or not; as a simple example, the
priorities of threads can change over time, etc, and it's not
clear how to keep that state in sync between the OS and
hardware, and so on.
So now I, as a systems software person, have to ask design
question around how I want to use these architectural features,
if at all, weighing various pros and cons. This is where I'm
struggling with your proposal: given that I'm going to have to
implement more general support for the things that the
architecture gives me anyway, what do I gain by also supporting
the specialized mechanisms? Particularly if, in order to use
them, I'm also forced into a "shape" for my system that's
dictated by the hardware, but that may not be the best for my
software? Is whatever the hardware gives me worth the tradeoff?
Right now, I'm not seeing it that it is. "It solves priority
inversion for the size of problems that it's applicable to" is
not enough to justify the additional cost of adoption. I have
to solve that problem anyway, whether I use this or not.
>> It doesn't seem like it can be usefully applied to
>> anything other than building traditional mutexes based on spin
>> locks, and even then I'm not sure if that's correct (see above).
>
>And here I thought you had an imagination .....
You admitted you're not an OS person and asked other people to
poke holes in your proposal. I'm sorry if you find the holes
I'm poking upsetting.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-26 09:55 -0400 |
| Message-ID | <jwv4izfncov.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111325 |
> Leaving aside the unchecked boundary conditions I highlighted
> above, there are other questions that this raises. You
> mentioned that the ESM stuff can use up to 8 cache lines in a
> single atomic "event"; let's count how many this code may
> encounter:
>
> 1. `from` may point to a cache line
> 2. `to` may point to a different cache line.
> 3. Does your architecture use a stack? What sort of alignment
> criteria do you impose? At first blush, it seems to me that
> the pointers `from_next`, `from_prev`, and `to_next` could be
> on the stack and if so, will be on at least one cache line,
> and possibly 2, if the call frame for `MoveElement` spans
> more than one. Of course, it's impossible to say when this
> is compiled, but maybe you require that the stack is always
> aligned to a cache line boundary or something. Or maybe
> these are all in registers and it's fine.
AFAIK the stack accesses will use normal loads that won't be tracked for
conflicts, so they don't count towards the 8 cache-lines limit.
> 4. Depending on the size and alignment criteria of the the
> `Element` structure and the placement of the `next` and
> `prev` elements in the struct (unknowable from this example),
> `to->next` may be on another cache line.
The coder may need to be careful with such slot placement and
alignment, indeed.
> So potentially this code _could_ touch 9 or 10 cache lines, more
> than you said are supported for a single atomic event. What
> happens in that case? Does the code just always return false?
I believe the code will indeed always return false in that case.
> If I understand this correctly, the `esmLOCKload`s are simply
> loads, but they make sure that the compiler emits instructions
> that tie into your atomic support framework. Earlier you wrote,
> "esmINTERFERENCE is a query on the state of the event and whether
> a 2nd party has performed a memory action that kills the event."
> Ok, I take this to mean _at the time of the store_, which
> appears later in the program.
No, I believe it is at the time when `esmINTERFERENCE` is called.
> If it were simply a query at the time it was written in the code, then
> it seems like it opens a TOCTOU bug (what if something interfers after
> the check, but before the the locked store at the end?).
IIUC the way this works is that in case there's a conflict later, the
other core will get a NACK (i.e. we'll win and they'll lose, even if
they have a higher priority) so we're guaranteed that we'll finish our
transaction successfully. Of course, that can be guaranteed only if we
already have "locked" the cache lines we'll need, which is what the
`esmLOCKprefetch` calls are about.
IOW the `esmINTERFERENCE` call is the time where the CPU decides whether
to "commit", and then the code between `esmINTERFERENCE` and
`esmLOCKstore` is the code which actually stores the changes we
decided to commit.
IIUC, the `esmINTERFERENCE` call is not needed, in which case the
operation should retry as many times as needed to succeed.
> Assuming nothing has poisoned the event, the various pointer
> stores inside the conditional are conditionally performed; the
> `esmLOCKstore` to `from->next` commits the event, at which
> point all side effects are exposed and durable.
The `esmLOCKstore` marks the end of the transaction. IIUC it can also
mark the "commit" but only if `esmINTERFERENCE` isn't used.
> So now I, as a systems software person, have to ask design
> question around how I want to use these architectural features,
> if at all, weighing various pros and cons. This is where I'm
> struggling with your proposal: given that I'm going to have to
> implement more general support for the things that the
> architecture gives me anyway, what do I gain by also supporting
> the specialized mechanisms?
I think the expectation is that you'd *use* those specialized mechanisms
but you wouldn't *support* them.
> Right now, I'm not seeing it that it is. "It solves priority
> inversion for the size of problems that it's applicable to" is
> not enough to justify the additional cost of adoption. I have
> to solve that problem anyway, whether I use this or not.
The ESM stuff is what you'll use at the assembly-level instead of T&S,
C&S, LL/SC because that's what the CPU supports/provides. But if you
prefer to code against T&S, C&S, LL/SC, AFAIK it'll work as well,
because you can "simulate" them easily with ESM.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-26 14:57 +0000 |
| Message-ID | <vs14k8$1a4$1@reader1.panix.com> |
| In reply to | #111328 |
In article <jwv4izfncov.fsf-monnier+comp.arch@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Leaving aside the unchecked boundary conditions I highlighted
>> above, there are other questions that this raises. You
>> mentioned that the ESM stuff can use up to 8 cache lines in a
>> single atomic "event"; let's count how many this code may
>> encounter:
>>
>> 1. `from` may point to a cache line
>> 2. `to` may point to a different cache line.
>> 3. Does your architecture use a stack? What sort of alignment
>> criteria do you impose? At first blush, it seems to me that
>> the pointers `from_next`, `from_prev`, and `to_next` could be
>> on the stack and if so, will be on at least one cache line,
>> and possibly 2, if the call frame for `MoveElement` spans
>> more than one. Of course, it's impossible to say when this
>> is compiled, but maybe you require that the stack is always
>> aligned to a cache line boundary or something. Or maybe
>> these are all in registers and it's fine.
>
>AFAIK the stack accesses will use normal loads that won't be tracked for
>conflicts, so they don't count towards the 8 cache-lines limit.
Ok, good to go.
>> 4. Depending on the size and alignment criteria of the the
>> `Element` structure and the placement of the `next` and
>> `prev` elements in the struct (unknowable from this example),
>> `to->next` may be on another cache line.
>
>The coder may need to be careful with such slot placement and
>alignment, indeed.
Yup. This could easily happen. Consider,
#include <stdalign.h>
#include <stdint.h>
#include <stdio.h>
struct elem {
struct elem *next;
struct elem *prev;
uint32_t data;
};
struct elem arr[40];
int
main()
{
printf("sizeof elem: %zu\n", sizeof(struct elem));
printf("alignof elem: %zu\n", alignof(struct elem));
printf("sizeof(arr): %zu\n", sizeof(arr));
return 0;
}
On, say, x86_64 with the SVR4 ABI, this has alignment 8 and
sizeof 24; presumably cache line size is a power of two, so
some of the elements of that array are going to spill over a
cache line.
>> So potentially this code _could_ touch 9 or 10 cache lines, more
>> than you said are supported for a single atomic event. What
>> happens in that case? Does the code just always return false?
>
>I believe the code will indeed always return false in that case.
That doesn't seem great. Surely there must be some way to
detect that the code did not meet the criteria for an atomic
event? What is the software recourse for recovery in this case?
>> If I understand this correctly, the `esmLOCKload`s are simply
>> loads, but they make sure that the compiler emits instructions
>> that tie into your atomic support framework. Earlier you wrote,
>> "esmINTERFERENCE is a query on the state of the event and whether
>> a 2nd party has performed a memory action that kills the event."
>> Ok, I take this to mean _at the time of the store_, which
>> appears later in the program.
>
>No, I believe it is at the time when `esmINTERFERENCE` is called.
>
>> If it were simply a query at the time it was written in the code, then
>> it seems like it opens a TOCTOU bug (what if something interfers after
>> the check, but before the the locked store at the end?).
>
>IIUC the way this works is that in case there's a conflict later, the
>other core will get a NACK (i.e. we'll win and they'll lose, even if
>they have a higher priority) so we're guaranteed that we'll finish our
>transaction successfully. Of course, that can be guaranteed only if we
>already have "locked" the cache lines we'll need, which is what the
>`esmLOCKprefetch` calls are about.
>
>IOW the `esmINTERFERENCE` call is the time where the CPU decides whether
>to "commit", and then the code between `esmINTERFERENCE` and
>`esmLOCKstore` is the code which actually stores the changes we
>decided to commit.
Curious. So what happens if a higher priority interrupt comes
in after the `esmINTERFERENCE` call, but before `esmLOCKstore`?
Earlier, Mitch wrote:
|My architecture has a mechanism to perform ATOMIC stuff over multiple
|instruction time frames that has the property that a higher priority
|thread which interferers with a lower priority thread, the HPT wins
|and the LPT fails its ATOMIC event. It is for exactly this reason
|that I drag priority through the memory hierarchy--so that real-time
|things remain closer to real-time (no or limited priority inversions).
This implies to me that the higher-prio interrupt would take
precedence, preempting the lower-priority critical section, and
the hardware would reuse the branch-prediction repair facility
to undo the effects of the atomic event before the store. But
what you wrote suggests that instead, perhaps, the higher
priority interrupt would be deferred until the store, in which
case, what happens if the code does something goofy like,
if (!esmINTERFERENCE())
for(;;) { /* Priority inversion */ }
I suppose this hinges on what it means for a thread to "fail its
ATOMIC event".
The thing that makes the most sense to me, given what you said
about the hardware automatically retrying, is that the point of
failure would be at the store. If that fails, the entire thing
is rewound and restarted from the first `esmLOCKload` since the
last `esmLOCKstore`; if `esmINTERFERENCE` returns true, it's
because `esmLOCKstore` has already been attempted and failed.
That would address the, "bonehead spins forever with interrupts
deferred" thing.
>IIUC, the `esmINTERFERENCE` call is not needed, in which case the
>operation should retry as many times as needed to succeed.
Ok. So,
void
spinlock_acquire(volatile Spinlock *lk)
{
while (esmLOCKload(&lk->lock) != 0)
relax();
esmLOCKstore(&lk->lock, 1);
}
Should be sufficient?
>> Assuming nothing has poisoned the event, the various pointer
>> stores inside the conditional are conditionally performed; the
>> `esmLOCKstore` to `from->next` commits the event, at which
>> point all side effects are exposed and durable.
>
>The `esmLOCKstore` marks the end of the transaction. IIUC it can also
>mark the "commit" but only if `esmINTERFERENCE` isn't used.
>
>> So now I, as a systems software person, have to ask design
>> question around how I want to use these architectural features,
>> if at all, weighing various pros and cons. This is where I'm
>> struggling with your proposal: given that I'm going to have to
>> implement more general support for the things that the
>> architecture gives me anyway, what do I gain by also supporting
>> the specialized mechanisms?
>
>I think the expectation is that you'd *use* those specialized mechanisms
>but you wouldn't *support* them.
Support in the sense that if I have software that uses them, I
need to support that software.
>> Right now, I'm not seeing it that it is. "It solves priority
>> inversion for the size of problems that it's applicable to" is
>> not enough to justify the additional cost of adoption. I have
>> to solve that problem anyway, whether I use this or not.
>
>The ESM stuff is what you'll use at the assembly-level instead of T&S,
>C&S, LL/SC because that's what the CPU supports/provides. But if you
>prefer to code against T&S, C&S, LL/SC, AFAIK it'll work as well,
>because you can "simulate" them easily with ESM.
The properties you mentioned earlier vis automatic retries and
code density sound attractive. The rest surrounding it, such as
the hardware's notion of a thread, priority, etc, less so. On
balance I remain skeptical that the tradeoff is worth it.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-26 13:22 -0700 |
| Message-ID | <vs1nlc$2h3d1$1@dont-email.me> |
| In reply to | #111330 |
On 3/26/2025 7:57 AM, Dan Cross wrote:
> In article <jwv4izfncov.fsf-monnier+comp.arch@gnu.org>,
> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> Leaving aside the unchecked boundary conditions I highlighted
>>> above, there are other questions that this raises. You
>>> mentioned that the ESM stuff can use up to 8 cache lines in a
>>> single atomic "event"; let's count how many this code may
>>> encounter:
>>>
>>> 1. `from` may point to a cache line
>>> 2. `to` may point to a different cache line.
>>> 3. Does your architecture use a stack? What sort of alignment
>>> criteria do you impose? At first blush, it seems to me that
>>> the pointers `from_next`, `from_prev`, and `to_next` could be
>>> on the stack and if so, will be on at least one cache line,
>>> and possibly 2, if the call frame for `MoveElement` spans
>>> more than one. Of course, it's impossible to say when this
>>> is compiled, but maybe you require that the stack is always
>>> aligned to a cache line boundary or something. Or maybe
>>> these are all in registers and it's fine.
>>
>> AFAIK the stack accesses will use normal loads that won't be tracked for
>> conflicts, so they don't count towards the 8 cache-lines limit.
>
> Ok, good to go.
>
>>> 4. Depending on the size and alignment criteria of the the
>>> `Element` structure and the placement of the `next` and
>>> `prev` elements in the struct (unknowable from this example),
>>> `to->next` may be on another cache line.
>>
>> The coder may need to be careful with such slot placement and
>> alignment, indeed.
>
> Yup. This could easily happen. Consider,
>
> #include <stdalign.h>
> #include <stdint.h>
> #include <stdio.h>
>
> struct elem {
> struct elem *next;
> struct elem *prev;
> uint32_t data;
> };
[...]
Indeed. Ideally, elem should be padded up to _and_ aligned on a l2 cache
line boundary to help get rid of false sharing. Also, the "anchor"
should be padded and aligned as well. An anchor can be:
struct anchor
{
std::atomic<elem*> m_head;
};
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-04-03 22:19 -0700 |
| Message-ID | <vsnq4d$2kcea$2@dont-email.me> |
| In reply to | #111335 |
On 3/26/2025 1:22 PM, Chris M. Thomasson wrote:
> On 3/26/2025 7:57 AM, Dan Cross wrote:
>> In article <jwv4izfncov.fsf-monnier+comp.arch@gnu.org>,
>> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>> Leaving aside the unchecked boundary conditions I highlighted
>>>> above, there are other questions that this raises. You
>>>> mentioned that the ESM stuff can use up to 8 cache lines in a
>>>> single atomic "event"; let's count how many this code may
>>>> encounter:
>>>>
>>>> 1. `from` may point to a cache line
>>>> 2. `to` may point to a different cache line.
>>>> 3. Does your architecture use a stack? What sort of alignment
>>>> criteria do you impose? At first blush, it seems to me that
>>>> the pointers `from_next`, `from_prev`, and `to_next` could be
>>>> on the stack and if so, will be on at least one cache line,
>>>> and possibly 2, if the call frame for `MoveElement` spans
>>>> more than one. Of course, it's impossible to say when this
>>>> is compiled, but maybe you require that the stack is always
>>>> aligned to a cache line boundary or something. Or maybe
>>>> these are all in registers and it's fine.
>>>
>>> AFAIK the stack accesses will use normal loads that won't be tracked for
>>> conflicts, so they don't count towards the 8 cache-lines limit.
>>
>> Ok, good to go.
>>
>>>> 4. Depending on the size and alignment criteria of the the
>>>> `Element` structure and the placement of the `next` and
>>>> `prev` elements in the struct (unknowable from this example),
>>>> `to->next` may be on another cache line.
>>>
>>> The coder may need to be careful with such slot placement and
>>> alignment, indeed.
>>
>> Yup. This could easily happen. Consider,
>>
>> #include <stdalign.h>
>> #include <stdint.h>
>> #include <stdio.h>
>>
>> struct elem {
>> struct elem *next;
>> struct elem *prev;
>> uint32_t data;
>> };
> [...]
>
> Indeed. Ideally, elem should be padded up to _and_ aligned on a l2 cache
> line boundary to help get rid of false sharing. Also, the "anchor"
> should be padded and aligned as well. An anchor can be:
>
> struct anchor
> {
> std::atomic<elem*> m_head;
> };
>
>
Actually, iirc pad and align the anchor to a reservation granule
boundary, then pad and align its nodes to l2 cache line boundaries.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-26 19:21 +0000 |
| Message-ID | <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org> |
| In reply to | #111325 |
On Wed, 26 Mar 2025 4:08:57 +0000, Dan Cross wrote:
> In article <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org>,
> MitchAlsup1 <mitchalsup@aol.com> wrote:
-----------------------
>>
>>You (well Chris) can write critical sections where a low priority
>>holder can give way to the higher priority requestor such that
>>the low priority holder reverts back to before it entered CS,
>>and does not see the lock being stolen.
>
> You still have not defined what you mean by, "the lock being
> stolen."
>
> Tell you what. Earlier, you posted some code for a critical
> section that inserts a node into a linked list. That code is
> written in terms of some primitives (presumably intrinsics,
> though you call them macros); `esmLOCKload`, `esmLOCKprefetch`,
> `esmINTERFERENCE` and `esmLOCKstore`. Here's that code, slightly
> reformatted:
>
> // Removes the element `from` from a doubly linked list, and
> // inserts it into a (possibly different) doubly linked list,
> // after the element pointed to be `to`.
> // Assumes <stdbool.h>
> bool
> MoveElement(Element *from, Element *to)
> {
> assert(from != NULL);
> assert(to != NULL);
>
> Element *from_next = esmLOCKload(from->next);
> Element *from_prev = esmLOCKload(from->prev);
> Element *to_next = esmLOCKload(to->next);
> esmLOCKprefetch(from_next);
> esmLOCKprefetch(from_prev);
> esmLOCKprefetch(to_next);
> if (!esmINTERFERENCE()) {
> // Unlink the "from" node from its list.
> from_prev->next = from_next; // XXX: `from_prev` may be nil?
> from_next->prev = from_prev; // XXX: `from_next` may be nil?
> // Insert the node after "to".
> to->next = from;
> to_next->prev = from; // XXX: `to_net` may be nil?
> from->prev = to;
> esmLOCKstore(from->next, to_next);
> return true;
> }
> return false;
> }
>
> Leaving aside the unchecked boundary conditions I highlighted
> above, there are other questions that this raises. You
> mentioned that the ESM stuff can use up to 8 cache lines in a
> single atomic "event"; let's count how many this code may
> encounter:
>
> 1. `from` may point to a cache line
> 2. `to` may point to a different cache line.
> 3. Does your architecture use a stack?
No
> What sort of alignment criteria do you impose?
On the participating data none. On the cache line--cache line.
> At first blush, it seems to me that
> the pointers `from_next`, `from_prev`, and `to_next` could be
> on the stack and if so, will be on at least one cache line,
> and possibly 2, if the call frame for `MoveElement` spans
> more than one.
The illustrated code is using 6 participating cache lines.
Where local variables are kept (stack, registers) does not
count against the tally of participating cache lines.
> Of course, it's impossible to say when this
> is compiled, but maybe you require that the stack is always
> aligned to a cache line boundary or something.
Data stack is DoubleWord aligned at all times.
> Or maybe
> these are all in registers and it's fine.
Local variables are not participating in the event--they are just
around to guide the event towards conclusion.
> 4. Depending on the size and alignment criteria of the the
> `Element` structure and the placement of the `next` and
> `prev` elements in the struct (unknowable from this example),
> `to->next` may be on another cache line.
> 5. Similarly, `from->next`
> 6. And `from->prev`
> 7. And `from_prev->next`
> 8. And `from_next->prev`
> 9. And `to_next->prev`.
>
> So potentially this code _could_ touch 9 or 10 cache lines, more
> than you said are supported for a single atomic event. What
> happens in that case? Does the code just always return false?
> The programmer best make sure the optimizer is keeping those
> temporary pointers off the stack; good luck with a debug build.
>
> Anyway, let's assume that's not the case, and we don't hit the
> pathological case with cache lines, and we're not dealing with
> edge cases at the front or end of the lists (so various next or
> prev pointers are not NULL). Why don't I try to explain what I
> think this code is doing, and you tell me whether I'm right or
> wrong.
>
> If I understand this correctly, the `esmLOCKload`s are simply
> loads, but they make sure that the compiler emits instructions
> that tie into your atomic support framework.
So far so good.
> Earlier you wrote,
> "esmINTERFERENCE is a query on the state of th event and whether
> a 2nd party has performed a memory action that kills the event."
> Ok, I take this to mean _at the time of the store_, which
> appears later in the program. If it were simply a query at the
> time it was written in the code, then it seems like it opens a
> TOCTOU bug (what if something interfers after the check, but
> before the the locked store at the end?). Or perhaps it signals
> to the architecture that this is the point to which the
> processor should rollback, if anything subsequently fails; sort
> of a `setjmp` kind of thing that conceptually returns twice.
The "if( esmINTERFERENCE() )" not only queries the state of the
participating cache lines, it sets up a guarding-shadow over
the STs to follow such that if killing-interference is detected
none of the STs are performed AND control is transferred to the
branch label (outside of the event). So not only does it query
the state at it execution, it monitors that over the rest of
the event.
BUT ALSO: it initializes the ability to NAK SNOOPs. The thought
is that if we have reached the manifestation phase of the event
(that is ready to do all the stores) then we should be able to
drive the event forward by not sending the data in response to
the SNOOP. We send a Nak (based on priority or the data)
If the SNOOPing core receives a NaK and it is not attempting an
event the request is simply reissued. If it is attempting, then
its event fails. So a core benignly accessing data that another
core is attempting an event upon, is delayed by an interconnect
round trip--but if it is attempting, it knows its event will
fail and it will either retry from before the event started,
or it will goto the interferrence-label where other facilities
\are at its disposal.
> Assuming nothing has poisoned the event, the various pointer
> stores inside the conditional are conditionally performed; the
> `esmLOCKstore` to `from->next` commits the event, at which
> point all side effects are exposed and durable.
From a SW perspective, that is accurate enough.
From a HW perspective, the participating STs are performed and
held in a buffer, and when it is known the event has succeeded,
a bit is flipped and these writes to memory all appear to have
been performed in the same cycle. One cycle earlier and no
interested 2nd party has seen any of them, the subsequent cycle
any interested 2nd party will see them all.
I should also note: ESM works even when there are no caches in
the system. ...
>
> Is that correct? Let's suppose that it is.
>
> But later you wrote,
>
>>So, if you want the property whereby the lock disappears on any
>>control transfer out of the event {exception, interrupt, SVC, SVR, ...};
>>then you want to use my ATOMIC stuff; otherwise, you can use the
>>normal ATOMIC primitives everyone and his brother provide.
>
> Well, what precisely do you mean here when you say, "if you want
> the property whereby the lock disappears on any control transfer
> out of the event"?
If you want that property--you use the tools at hand.
If you don't just use them as primitive generators.
> What I _hope_ you mean is that if you transfer "out of the
> event" before the `esmLOCKstore` then anything that's been done
> since the "event" started is rolled back, but NOT if control
> transfer happens _after_ the `esmLOCKstore`. If THAT were the
> case, then this entire mechanism is useless.
One can use a esmLOCKstore( *SP, 0 ) to abandon an event. HW
detects that *SP is not participating in the event, and uses
the lock bit in the instruction to know it is time to leave
the event in the failed manner. No ST is performed to the
non-participating cache line. {{I guess I could wrap the
abandonment into a macro ...}}
> Perhaps you would clarify?
>
> But for the time being, let's assume that `esmLOCKstore` is
> conceptually a commit that ends the atomic event, and the store
> is durable and observable after that. Let's see if we can
> construct a simple spinlock from these primitives.
Notice that only the last ST has the esmLOCKstore() applied.
HW knows that STs to participating lines have the ATOMIC
property. The final ST uses the LOCK bit to denote the end
of the event.
>
> typedef struct Spinlock Spinlock;
> struct Spinlock {
> uint32_t lock;
> };
>
> uint32_t
> xcas(volatile Spinlock *lk, uint32_t expected, uint32_t val)
> {
> uint32_t v = esmLOCKload(&lk->lock);
> if (v == expected && !esmINTERFERENCE()) {
> esmLOCKstore(&lk->lock, val)
> }
> return v;
> }
If the interference check is desired at all:: (see below)
I think you should move interference check in front of the
expected check, but that is a first impression--have to think
about it more.
> void
> spin_acquire(volatile Spinlock *lk)
> {
> splhi();
> while (xcas(lk, 0, 1) != 0)
> relax(); // Spin loop intrinsic.
> }
>
> void
> spin_release(volatile Spinlock *lk)
> {
> xcas(lk, 1, 0);
> // Maybe we should `spllo` here, maybe not. Either choice
> // reflects lots of assumptions about whether or not we might
> // take and hold multiple locks concurrently, etc.
> spllo();
> }
>
> Does this seem correct? It is not immediately clear to me
> whether `esmINTERFERENCE` is actually needed here, but
> avoiding the store seemed fine.
There are MANY cases where the interference query is not needed.
Without the interference query, deadly interference backs the
core up to the first instruction of the event. With the interference
check, if deadly interference happens before the query, control
reverts to before the event, and afterwards, control is transferred
to the interference-label.
> One could imagine shorting
> `xcas` to simply:
>
> uint32_t
> xcas(volatile Spinlock *lk, uint32_t expected, uint32_t val)
> {
> uint32_t v = esmLOCKload(&lk->lock);
> if (v == expected) esmLOCKstore(&lk->lock, val);
> return v;
> }
Yes, unless you want the alternate exit strategy, this works fine.
In fact test and set is written::
boolean char TestAndSet( type char *p )
{
boolean t = esmLOCKload ( *p );
esmLOCKstore( *p, 1 );
return t;
}
Should interference transpire between load and store control
reverts back to the LD again, so the return value is the LD
which did not encounter interference.
> or perhaps:
>
> uint32_t
> xswap(volatile Spinlock *lk, uint32_t val)
> {
> uint32_t v = esmLOCKload(&lk->lock);
> esmLOCKstore(&lk->lock, val);
> return v;
> }
>
> But that all depends on the specifics of the atomics.
>
>>For the sizes of CSs this covers--it prevent priority inversion.
>
> Except you've admitted that this is not a general solution, as
> it cannot "cover" arbitrary software-defined critical sections:
> the window isn't big enough and we've seen how even a fairly
> small problem may exceed the number of cache lines supported by
> one of these events.
Remember only the lines participating in the event count. For
example, say one had sprintf() inside the event. None of the
lines touched by springt() are participating in the event,
and are not counted against the 8 cache lines available.
---------------------
> So now I, as a systems software person, have to ask design
> question around how I want to use these architectural features,
> if at all, weighing various pros and cons. This is where I'm
> struggling with your proposal: given that I'm going to have to
> implement more general support for the things that the
> architecture gives me anyway, what do I gain by also supporting
> the specialized mechanisms?
All I can say about this, was that when I presented ASF (ESM's
predecessor) to Microsoft and spend a couple hours explaining
to them how it works, MS wanted it implemented as rapidly as
AMD could pull it off. Dave Cutler was particularly impressed.
----------------------
>>And here I thought you had an imagination .....
>
> You admitted you're not an OS person and asked other people to
> poke holes in your proposal. I'm sorry if you find the holes
> I'm poking upsetting.
I enjoy your poking of holes--I really do
But you seem like the calculus student that keeps asking what
problem can I solve now that I can differentiate.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-26 15:41 -0400 |
| Message-ID | <jwvcye3twfr.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111331 |
>> uint32_t
>> xcas(volatile Spinlock *lk, uint32_t expected, uint32_t val)
>> {
>> uint32_t v = esmLOCKload(&lk->lock);
>> if (v == expected) esmLOCKstore(&lk->lock, val);
>> return v;
>> }
>
> Yes, unless you want the alternate exit strategy, this works fine.
How does ESM know that the "event" is complete when the code doesn't go
through the final `esmLOCKstore`?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-26 15:50 -0400 |
| Message-ID | <jwv7c4btw6l.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111331 |
> Remember only the lines participating in the event count. For
> example, say one had sprintf() inside the event. None of the
> lines touched by sprint() are participating in the event,
> and are not counted against the 8 cache lines available.
Hmm... so if I need to add a "participating line" to which I need to
store but that I don't need to read, I still need to do a "useless"
`esmLOCKload` before the (normal) store, just to mark the line as
participating in the event?
I guess it's a rather rare need.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-26 23:16 +0000 |
| Message-ID | <3f5e3b50120acd5dd4649fa4625c68f2@www.novabbs.org> |
| In reply to | #111334 |
On Wed, 26 Mar 2025 19:50:14 +0000, Stefan Monnier wrote: >> Remember only the lines participating in the event count. For >> example, say one had sprintf() inside the event. None of the >> lines touched by sprint() are participating in the event, >> and are not counted against the 8 cache lines available. > > Hmm... so if I need to add a "participating line" to which I need to > store but that I don't need to read, I still need to do a "useless" > `esmLOCKload` before the (normal) store, just to mark the line as > participating in the event? use esmLOCKprefetch() for bringing data towards the cache without wasting a register on containing its value. > I guess it's a rather rare need. Rare enough it was illustrated in my very first example. > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-26 21:35 +0000 |
| Message-ID | <9q_EP.688441$SVG3.221243@fx42.iad> |
| In reply to | #111331 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Wed, 26 Mar 2025 4:08:57 +0000, Dan Cross wrote: > >> In article <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org>, > >> Earlier you wrote, >> "esmINTERFERENCE is a query on the state of th event and whether >> a 2nd party has performed a memory action that kills the event." >> Ok, I take this to mean _at the time of the store_, which >> appears later in the program. If it were simply a query at the >> time it was written in the code, then it seems like it opens a >> TOCTOU bug (what if something interfers after the check, but >> before the the locked store at the end?). Or perhaps it signals >> to the architecture that this is the point to which the >> processor should rollback, if anything subsequently fails; sort >> of a `setjmp` kind of thing that conceptually returns twice. > >The "if( esmINTERFERENCE() )" not only queries the state of the >participating cache lines, it sets up a guarding-shadow over >the STs to follow such that if killing-interference is detected >none of the STs are performed AND control is transferred to the >branch label (outside of the event). So not only does it query >the state at it execution, it monitors that over the rest of >the event. > >BUT ALSO: it initializes the ability to NAK SNOOPs. The thought >is that if we have reached the manifestation phase of the event >(that is ready to do all the stores) then we should be able to >drive the event forward by not sending the data in response to >the SNOOP. We send a Nak (based on priority or the data) If you can NAK a snoop, are you then assuming that all DMA is non-coherent? That will really piss off the kernel folks.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-26 23:22 +0000 |
| Message-ID | <3061a58cdec38c3aa6093cbb74ea004a@www.novabbs.org> |
| In reply to | #111336 |
On Wed, 26 Mar 2025 21:35:01 +0000, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >>On Wed, 26 Mar 2025 4:08:57 +0000, Dan Cross wrote: >> >>> In article <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org>, > >> >>> Earlier you wrote, >>> "esmINTERFERENCE is a query on the state of th event and whether >>> a 2nd party has performed a memory action that kills the event." >>> Ok, I take this to mean _at the time of the store_, which >>> appears later in the program. If it were simply a query at the >>> time it was written in the code, then it seems like it opens a >>> TOCTOU bug (what if something interfers after the check, but >>> before the the locked store at the end?). Or perhaps it signals >>> to the architecture that this is the point to which the >>> processor should rollback, if anything subsequently fails; sort >>> of a `setjmp` kind of thing that conceptually returns twice. >> >>The "if( esmINTERFERENCE() )" not only queries the state of the >>participating cache lines, it sets up a guarding-shadow over >>the STs to follow such that if killing-interference is detected >>none of the STs are performed AND control is transferred to the >>branch label (outside of the event). So not only does it query >>the state at it execution, it monitors that over the rest of >>the event. >> >>BUT ALSO: it initializes the ability to NAK SNOOPs. The thought >>is that if we have reached the manifestation phase of the event >>(that is ready to do all the stores) then we should be able to >>drive the event forward by not sending the data in response to >>the SNOOP. We send a Nak (based on priority or the data) > > If you can NAK a snoop, are you then assuming that all DMA is > non-coherent? That will really piss off the kernel folks. Not at all. DMA is as coherent as the I/O MMU's translating PTE prescribes. But; why would any sane coder be performing an ATOMIC event on memory that can be blindly overwritten by DMA ??? Or for that mater, critical section data being overwritten (at some unknown and unpredictable time) by DMA ??
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web