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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-24 14:02 -0400 |
| Message-ID | <jwva59a48v6.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111265 |
MitchAlsup1 [2025-03-24 17:36:28] wrote:
> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote:
>> Consider something as simple as popping an item off of the front
>> of a queue and inserting it into an ordered singly-linked list:
[...]
> I have almost that in the documentation for my ATOMIC stuff::
> The following code moves a doubly linked element from one place
> in a concurrent data structure to another without any interested
> 3rd party being able to see that the element is now within the
> CDS at any time::
Would your "ATOMIC stuff" really handle Dan's example, tho?
A key element in Dan's example if the "ordered singly-linked list",
i.e. you need to walk the list an unbounded number of steps until you
can find the insertion point, so I don't think you can do the whole
thing inside your ATOMIC stuff.
IOW, you'd have to somehow move the list-walk outside of the atomic section.
E.g. if you know elements are only ever removed from the tail of the
list, you can presumably walk the list outside of the ATOMIC stuff and
then do the "remove from the queue and insert into the list" atomically
since it's a small&finite number of steps (with a test to loop back to
the list-walk if someone else inserted or removed anything at that point
in the mean time).
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-24 19:09 +0000 |
| Message-ID | <96987d473656f296ec63c30626a46730@www.novabbs.org> |
| In reply to | #111268 |
On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote: > MitchAlsup1 [2025-03-24 17:36:28] wrote: >> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote: >>> Consider something as simple as popping an item off of the front >>> of a queue and inserting it into an ordered singly-linked list: > [...] >> I have almost that in the documentation for my ATOMIC stuff:: >> The following code moves a doubly linked element from one place >> in a concurrent data structure to another without any interested >> 3rd party being able to see that the element is now within the >> CDS at any time:: > > Would your "ATOMIC stuff" really handle Dan's example, tho? > A key element in Dan's example if the "ordered singly-linked list", > i.e. you need to walk the list an unbounded number of steps until you > can find the insertion point, so I don't think you can do the whole > thing inside your ATOMIC stuff. Technically, yes, you can put a search loop in an ATOOMIC event. Whether you want to or not is a different story. My example illustrated the ATOMIC manipulation of the event without a search. In addition, if the search it long, code developer should either to the search before the event, or grab a Mutex to prevent interference during the search and rest of the critical region. > IOW, you'd have to somehow move the list-walk outside of the atomic > section. Yes, > E.g. if you know elements are only ever removed from the tail of the > list, you can presumably walk the list outside of the ATOMIC stuff and > then do the "remove from the queue and insert into the list" atomically > since it's a small&finite number of steps (with a test to loop back to > the list-walk if someone else inserted or removed anything at that point > in the mean time). Or maintain a tail pointer. > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 20:28 +0000 |
| Message-ID | <vrsf9o$c6m$1@reader1.panix.com> |
| In reply to | #111274 |
In article <96987d473656f296ec63c30626a46730@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote: > >> MitchAlsup1 [2025-03-24 17:36:28] wrote: >>> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote: >>>> Consider something as simple as popping an item off of the front >>>> of a queue and inserting it into an ordered singly-linked list: >> [...] >>> I have almost that in the documentation for my ATOMIC stuff:: >>> The following code moves a doubly linked element from one place >>> in a concurrent data structure to another without any interested >>> 3rd party being able to see that the element is now within the >>> CDS at any time:: >> >> Would your "ATOMIC stuff" really handle Dan's example, tho? >> A key element in Dan's example if the "ordered singly-linked list", >> i.e. you need to walk the list an unbounded number of steps until you >> can find the insertion point, so I don't think you can do the whole >> thing inside your ATOMIC stuff. > >Technically, yes, you can put a search loop in an ATOOMIC event. >Whether you want to or not is a different story. My example >illustrated the ATOMIC manipulation of the event without a search. > >In addition, if the search it long, code developer should either >to the search before the event, or grab a Mutex to prevent >interference during the search and rest of the critical region. The problem, as specified, excluded this idea that the list was long. The point was simply to show a scenario where your atomic operation proposal breaks down, and where you might want to disable interrupt delivery. The point wasn't to ask whether the specific problem could be recast in a different way; it probably can. The question was to ask whether your proposal could support that specific problem. I don't see how it can. >> IOW, you'd have to somehow move the list-walk outside of the atomic >> section. > >Yes, > >> E.g. if you know elements are only ever removed from the tail of the >> list, you can presumably walk the list outside of the ATOMIC stuff and >> then do the "remove from the queue and insert into the list" atomically >> since it's a small&finite number of steps (with a test to loop back to >> the list-walk if someone else inserted or removed anything at that point >> in the mean time). > >Or maintain a tail pointer. There's no guarantee that the tail is the correct place to insert the element, vis the order of the elements. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-24 22:29 +0000 |
| Message-ID | <684d32898ec85b91bcb9dcdb97d8065a@www.novabbs.org> |
| In reply to | #111279 |
On Mon, 24 Mar 2025 20:28:40 +0000, Dan Cross wrote: > In article <96987d473656f296ec63c30626a46730@www.novabbs.org>, > MitchAlsup1 <mitchalsup@aol.com> wrote: >>On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote: >> >>> MitchAlsup1 [2025-03-24 17:36:28] wrote: >>>> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote: >>>>> Consider something as simple as popping an item off of the front >>>>> of a queue and inserting it into an ordered singly-linked list: >>> [...] >>>> I have almost that in the documentation for my ATOMIC stuff:: >>>> The following code moves a doubly linked element from one place >>>> in a concurrent data structure to another without any interested >>>> 3rd party being able to see that the element is now within the >>>> CDS at any time:: >>> >>> Would your "ATOMIC stuff" really handle Dan's example, tho? >>> A key element in Dan's example if the "ordered singly-linked list", >>> i.e. you need to walk the list an unbounded number of steps until you >>> can find the insertion point, so I don't think you can do the whole >>> thing inside your ATOMIC stuff. >> >>Technically, yes, you can put a search loop in an ATOOMIC event. >>Whether you want to or not is a different story. My example >>illustrated the ATOMIC manipulation of the event without a search. >> >>In addition, if the search it long, code developer should either >>to the search before the event, or grab a Mutex to prevent >>interference during the search and rest of the critical region. > > The problem, as specified, excluded this idea that the list was > long. > > The point was simply to show a scenario where your atomic > operation proposal breaks down, and where you might want to > disable interrupt delivery. My ATOMIC stuff allows for the construction, in SW, of pretty much any ATOMIC primitive anyone would like. It is, in general, not suited to guard critical regions, but to grab the lock which does. Most uses of My ATOMIC stuff is to grab/change/update data that then guards various critical regions. More like a multi- valued version of LDL-STC. > The point wasn't to ask whether > the specific problem could be recast in a different way; it > probably can. The question was to ask whether your proposal > could support that specific problem. I don't see how it can. To the question posed, you should just grab the lock/mutex. >>> IOW, you'd have to somehow move the list-walk outside of the atomic >>> section. >> >>Yes, >> >>> E.g. if you know elements are only ever removed from the tail of the >>> list, you can presumably walk the list outside of the ATOMIC stuff and >>> then do the "remove from the queue and insert into the list" atomically >>> since it's a small&finite number of steps (with a test to loop back to >>> the list-walk if someone else inserted or removed anything at that point >>> in the mean time). >> >>Or maintain a tail pointer. > > There's no guarantee that the tail is the correct place to > insert the element, vis the order of the elements. If the element pointer updates and the tail pointer update are inside one of my ATOMIC events, then you are sure that the tail pointer is always pointing at the last element in the list (if there is one). > - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 23:27 +0000 |
| Message-ID | <vrspp6$jpn$1@reader1.panix.com> |
| In reply to | #111280 |
In article <684d32898ec85b91bcb9dcdb97d8065a@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >On Mon, 24 Mar 2025 20:28:40 +0000, Dan Cross wrote: >> In article <96987d473656f296ec63c30626a46730@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote: >>> >>>> MitchAlsup1 [2025-03-24 17:36:28] wrote: >>>>> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote: >>>>>> Consider something as simple as popping an item off of the front >>>>>> of a queue and inserting it into an ordered singly-linked list: >>>> [...] >>>>> I have almost that in the documentation for my ATOMIC stuff:: >>>>> The following code moves a doubly linked element from one place >>>>> in a concurrent data structure to another without any interested >>>>> 3rd party being able to see that the element is now within the >>>>> CDS at any time:: >>>> >>>> Would your "ATOMIC stuff" really handle Dan's example, tho? >>>> A key element in Dan's example if the "ordered singly-linked list", >>>> i.e. you need to walk the list an unbounded number of steps until you >>>> can find the insertion point, so I don't think you can do the whole >>>> thing inside your ATOMIC stuff. >>> >>>Technically, yes, you can put a search loop in an ATOOMIC event. >>>Whether you want to or not is a different story. My example >>>illustrated the ATOMIC manipulation of the event without a search. >>> >>>In addition, if the search it long, code developer should either >>>to the search before the event, or grab a Mutex to prevent >>>interference during the search and rest of the critical region. >> >> The problem, as specified, excluded this idea that the list was >> long. >> >> The point was simply to show a scenario where your atomic >> operation proposal breaks down, and where you might want to >> disable interrupt delivery. > >My ATOMIC stuff allows for the construction, in SW, of pretty >much any ATOMIC primitive anyone would like. It is, in general, >not suited to guard critical regions, but to grab the lock which >does. Ok, that's good to understand. >Most uses of My ATOMIC stuff is to grab/change/update data >that then guards various critical regions. More like a multi- >valued version of LDL-STC. I don't see how constructing the primitive that way is terribly useful compared to just issuing multiple load-locked/store-cond instructions; in particular, it doesn't seem like the sort of thing that composes well: every sequence that uses it must be coded to use it, explicitly, instead of just nesting calls to "lock". >> The point wasn't to ask whether >> the specific problem could be recast in a different way; it >> probably can. The question was to ask whether your proposal >> could support that specific problem. I don't see how it can. > >To the question posed, you should just grab the lock/mutex. That's fine, then. But this is another example of a place where one probably wants to disable interrupts while in the critical section, to avoid being preempted while holding the lock. >>>> IOW, you'd have to somehow move the list-walk outside of the atomic >>>> section. >>> >>>Yes, >>> >>>> E.g. if you know elements are only ever removed from the tail of the >>>> list, you can presumably walk the list outside of the ATOMIC stuff and >>>> then do the "remove from the queue and insert into the list" atomically >>>> since it's a small&finite number of steps (with a test to loop back to >>>> the list-walk if someone else inserted or removed anything at that point >>>> in the mean time). >>> >>>Or maintain a tail pointer. >> >> There's no guarantee that the tail is the correct place to >> insert the element, vis the order of the elements. > >If the element pointer updates and the tail pointer update are inside >one of my ATOMIC events, then you are sure that the tail pointer is >always pointing at the last element in the list (if there is one). But that's irrelevant. The goal is to insert into a sorted list and, again, the last element is not necessarily the correct place to insert (or append). - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-25 13:43 +0000 |
| Message-ID | <8qyEP.1257951$FVcd.630606@fx10.iad> |
| In reply to | #111282 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <684d32898ec85b91bcb9dcdb97d8065a@www.novabbs.org>, >MitchAlsup1 <mitchalsup@aol.com> wrote: >>My ATOMIC stuff allows for the construction, in SW, of pretty >>much any ATOMIC primitive anyone would like. It is, in general, >>not suited to guard critical regions, but to grab the lock which >>does. > >Ok, that's good to understand. > >>Most uses of My ATOMIC stuff is to grab/change/update data >>that then guards various critical regions. More like a multi- >>valued version of LDL-STC. > >I don't see how constructing the primitive that way is terribly >useful compared to just issuing multiple load-locked/store-cond >instructions; in particular, it doesn't seem like the sort of >thing that composes well: every sequence that uses it must be >coded to use it, explicitly, instead of just nesting calls to >"lock". LL/SC has been shown to be less efficient for contended locks than atomic operations when the core count exceeds single digits. It's difficult to argue against the standard set of atomic primitives (the PCIe set: compare and swap, load and add, swap) for scalability; ARM has extended the list to include exclusive or, set-bit, clear-bit, min, max, et al. Analysis comparing with LL/SC: https://cpufun.substack.com/p/atomics-in-aarch64
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 15:08 +0000 |
| Message-ID | <vrugt2$lqf$1@reader1.panix.com> |
| In reply to | #111295 |
In article <8qyEP.1257951$FVcd.630606@fx10.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <684d32898ec85b91bcb9dcdb97d8065a@www.novabbs.org>, >>MitchAlsup1 <mitchalsup@aol.com> wrote: > >>>My ATOMIC stuff allows for the construction, in SW, of pretty >>>much any ATOMIC primitive anyone would like. It is, in general, >>>not suited to guard critical regions, but to grab the lock which >>>does. >> >>Ok, that's good to understand. >> >>>Most uses of My ATOMIC stuff is to grab/change/update data >>>that then guards various critical regions. More like a multi- >>>valued version of LDL-STC. >> >>I don't see how constructing the primitive that way is terribly >>useful compared to just issuing multiple load-locked/store-cond >>instructions; in particular, it doesn't seem like the sort of >>thing that composes well: every sequence that uses it must be >>coded to use it, explicitly, instead of just nesting calls to >>"lock". > >LL/SC has been shown to be less efficient for contended >locks than atomic operations when the core count exceeds >single digits. > >It's difficult to argue against the standard set of atomic >primitives (the PCIe set: compare and swap, load and add, >swap) for scalability; ARM has extended the list to >include exclusive or, set-bit, clear-bit, min, max, et al. > >Analysis comparing with LL/SC: > >https://cpufun.substack.com/p/atomics-in-aarch64 That analysis is interesting; thanks for pointing it out. I'm not sure that it is directly applicable to locks, though, since it's primarily concerned with atomic increment. Semaphores, perhaps; something like `ldaddal` would work well in the implementation of `xadd`, as in this paper by Mullender and Cox: https://swtch.com/semaphore.pdf Highly contended spin locks based on CAS loops tend not to scale well as core counts increase, hence more elaborate lock types like MCS locks, CLH locks, and so on. Boyd-Wickizer et al go into this in detail in https://people.csail.mit.edu/nickolai/papers/boyd-wickizer-locks.pdf I rather doubt that single-instruction atomics versus LL-SC are a going to make a big difference here. But I also wonder at the internal implementation of these instructions in e.g. that Fujitsu chip that allows throughput to stay more or less constant as the number of cores increases; I'd think that cache coherency traffic as threads contend for a single cache line would create a bottleneck leading to (at least) a linear slow down. This suggests to me that perhaps the performance characteristcs are less in the specific instructions used (one versus LL-SC), but rather how those instructions are implemented with respect to the coherency protocol. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-25 11:48 -0400 |
| Message-ID | <jwviknxp0zj.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111299 |
> a going to make a big difference here. But I also wonder at the
> internal implementation of these instructions in e.g. that
> Fujitsu chip that allows throughput to stay more or less
> constant as the number of cores increases; I'd think that cache
> coherency traffic as threads contend for a single cache line
> would create a bottleneck leading to (at least) a linear
> slow down.
IIUC the idea is that the atomic-add is sent to the memory and performed
there, instead of moving the data to the cache. So there's no
contention for the cache line because the data is not in a cache at all.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-25 16:29 +0000 |
| Message-ID | <pRAEP.1333398$_N6e.449674@fx17.iad> |
| In reply to | #111301 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: >> a going to make a big difference here. But I also wonder at the >> internal implementation of these instructions in e.g. that >> Fujitsu chip that allows throughput to stay more or less >> constant as the number of cores increases; I'd think that cache >> coherency traffic as threads contend for a single cache line >> would create a bottleneck leading to (at least) a linear >> slow down. > >IIUC the idea is that the atomic-add is sent to the memory and performed >there, instead of moving the data to the cache. So there's no >contention for the cache line because the data is not in a cache at all. Exactly. The LLC may also support the atomics directly. Additionally, with PCIe, the atomic can be executed at the endpoint function.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-25 13:28 -0400 |
| Message-ID | <jwvcye5owfb.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111302 |
>>IIUC the idea is that the atomic-add is sent to the memory and performed
>>there, instead of moving the data to the cache. So there's no
>>contention for the cache line because the data is not in a cache at all.
>
> Exactly. The LLC may also support the atomics directly.
>
> Additionally, with PCIe, the atomic can be executed at
> the endpoint function.
It should even be possible (no idea if anyone tried to implement it) to
combine the operations as they bubble up the memory, so your
N increments on your N cores can turn into N/64 additions of 64 leaving
each group of 64 cores, making it possible to scale with the number
of cores.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-25 13:53 -0400 |
| Message-ID | <V4CEP.125361$Xq5f.89768@fx38.iad> |
| In reply to | #111302 |
Scott Lurndal wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> a going to make a big difference here. But I also wonder at the >>> internal implementation of these instructions in e.g. that >>> Fujitsu chip that allows throughput to stay more or less >>> constant as the number of cores increases; I'd think that cache >>> coherency traffic as threads contend for a single cache line >>> would create a bottleneck leading to (at least) a linear >>> slow down. >> IIUC the idea is that the atomic-add is sent to the memory and performed >> there, instead of moving the data to the cache. So there's no >> contention for the cache line because the data is not in a cache at all. > > Exactly. The LLC may also support the atomics directly. > > Additionally, with PCIe, the atomic can be executed at > the endpoint function. Those features are possible but there is no indication that is what that web page is measuring. I agree with Dan that looks more like a test of the cache efficiency or the cache line pinning mechanism than a test of LL/SC vs AtomicXxxx. First, it doesn't say what systems these are on. It says the cores is Cavium Thunder X2 and Fujitsu A64FX but does not describe the systems. For each platform it needed to establish a base line performance for moving lines between caches, the same ++ loops but without atomics. Also Arm is weak ordered. At least one version of those test loops should have fences otherwise this doesn't tell you anything about how it might behave in real use. And as a general guideline, I tend to distrust concurrency benchmarks which sit in a tight loop hammering a single memory location because they greatly favor whichever core is currently holding the cache line. By artificially inflating the contention they really tell you little about how it will behave in real world use where there are time gaps between core accesses allowing lines to move.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-25 20:33 +0000 |
| Message-ID | <gqEEP.752814$SZca.118704@fx13.iad> |
| In reply to | #111308 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >Scott Lurndal wrote: >> Stefan Monnier <monnier@iro.umontreal.ca> writes: >>>> a going to make a big difference here. But I also wonder at the >>>> internal implementation of these instructions in e.g. that >>>> Fujitsu chip that allows throughput to stay more or less >>>> constant as the number of cores increases; I'd think that cache >>>> coherency traffic as threads contend for a single cache line >>>> would create a bottleneck leading to (at least) a linear >>>> slow down. >>> IIUC the idea is that the atomic-add is sent to the memory and performed >>> there, instead of moving the data to the cache. So there's no >>> contention for the cache line because the data is not in a cache at all. >> >> Exactly. The LLC may also support the atomics directly. >> >> Additionally, with PCIe, the atomic can be executed at >> the endpoint function. > >Those features are possible but there is no indication that is >what that web page is measuring. > >I agree with Dan that looks more like a test of the cache efficiency or >the cache line pinning mechanism than a test of LL/SC vs AtomicXxxx. > >First, it doesn't say what systems these are on. >It says the cores is Cavium Thunder X2 and Fujitsu A64FX >but does not describe the systems. There were actually two Thunder X2 chips - the original was the Cavium in-house design, the second was based on the Vulcan design that Cavium bought from Broadcom. The Cavium Thunderx2 chip was rebranded OcteonTx and aimed at the networking market, while the Vulcan was named ThunderX2 and sold into the server space. > >For each platform it needed to establish a base line performance for >moving lines between caches, the same ++ loops but without atomics. > >Also Arm is weak ordered. At least one version of those test loops should >have fences otherwise this doesn't tell you anything about how it might >behave in real use. The memory model is formally defined in the ARM Architecture manual. There are a number of methods available to deal with ordering and consistency, including a memory barrier instruction (DMB) which can be applied globally or within sharability domains.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 17:47 +0000 |
| Message-ID | <vruq6v$cv2$2@reader1.panix.com> |
| In reply to | #111301 |
In article <jwviknxp0zj.fsf-monnier+comp.arch@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> a going to make a big difference here. But I also wonder at the >> internal implementation of these instructions in e.g. that >> Fujitsu chip that allows throughput to stay more or less >> constant as the number of cores increases; I'd think that cache >> coherency traffic as threads contend for a single cache line >> would create a bottleneck leading to (at least) a linear >> slow down. > >IIUC the idea is that the atomic-add is sent to the memory and performed >there, instead of moving the data to the cache. So there's no >contention for the cache line because the data is not in a cache at all. Interesting; that's very clever. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-03-27 10:55 +0100 |
| Message-ID | <vs379s$3vr1j$1@dont-email.me> |
| In reply to | #111301 |
Stefan Monnier wrote: >> a going to make a big difference here. But I also wonder at the >> internal implementation of these instructions in e.g. that >> Fujitsu chip that allows throughput to stay more or less >> constant as the number of cores increases; I'd think that cache >> coherency traffic as threads contend for a single cache line >> would create a bottleneck leading to (at least) a linear >> slow down. > > IIUC the idea is that the atomic-add is sent to the memory and performed > there, instead of moving the data to the cache. So there's no > contention for the cache line because the data is not in a cache at all. This one I have never understood the use/need for, except to provide global shared counters of some sort: In that case it would make perfect sense to allow any core to send (and immediately forget) a message "increment counter X by 1", but at least in my own coding, any LOCK XADD has been performed because I now need to do something with either the previous or the updated value of the counter. Having the atomic-add performed by a memory controller, returning the result, would make it almost perfectly scalable, but would also limit the speed of this operation to the bus transaction speed, even when there is zero contention, right? I guess if the atomic-add has been implemented at all/most cache levels as well, then it would indeed perform better for all workloads, the problem is that under contention you still have to flush the variable out to the RAM array, right? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-27 20:31 +0000 |
| Message-ID | <1982332838be0567e544d0282969fe36@www.novabbs.org> |
| In reply to | #111341 |
On Thu, 27 Mar 2025 9:55:08 +0000, Terje Mathisen wrote: > Stefan Monnier wrote: >>> a going to make a big difference here. But I also wonder at the >>> internal implementation of these instructions in e.g. that >>> Fujitsu chip that allows throughput to stay more or less >>> constant as the number of cores increases; I'd think that cache >>> coherency traffic as threads contend for a single cache line >>> would create a bottleneck leading to (at least) a linear >>> slow down. >> >> IIUC the idea is that the atomic-add is sent to the memory and performed >> there, instead of moving the data to the cache. So there's no >> contention for the cache line because the data is not in a cache at all. > > This one I have never understood the use/need for, except to provide > global shared counters of some sort: > > In that case it would make perfect sense to allow any core to send (and > immediately forget) a message "increment counter X by 1", but at least > in my own coding, any LOCK XADD has been performed because I now need to > do something with either the previous or the updated value of the > counter. > > Having the atomic-add performed by a memory controller, returning the > result, would make it almost perfectly scalable, but would also limit > the speed of this operation to the bus transaction speed, even when > there is zero contention, right? Yes, BUT:: If the atomic-add is performed at the level in the cache having write permission on the data, then, much of the time, the interconnect speed and latency becomes way-less pronounced. > I guess if the atomic-add has been implemented at all/most cache levels > as well, then it would indeed perform better for all workloads, the > problem is that under contention you still have to flush the variable > out to the RAM array, right? My point exactly. Let's face it, the size of an integer adder compared to the area of the SRAMs making up the cache is insignificant--even at the L1 level. > > Terje
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-24 19:08 -0700 |
| Message-ID | <vrt37r$27c13$4@dont-email.me> |
| In reply to | #111279 |
On 3/24/2025 1:28 PM, Dan Cross wrote: > In article <96987d473656f296ec63c30626a46730@www.novabbs.org>, > MitchAlsup1 <mitchalsup@aol.com> wrote: >> On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote: >> >>> MitchAlsup1 [2025-03-24 17:36:28] wrote: >>>> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote: >>>>> Consider something as simple as popping an item off of the front >>>>> of a queue and inserting it into an ordered singly-linked list: >>> [...] >>>> I have almost that in the documentation for my ATOMIC stuff:: >>>> The following code moves a doubly linked element from one place >>>> in a concurrent data structure to another without any interested >>>> 3rd party being able to see that the element is now within the >>>> CDS at any time:: >>> >>> Would your "ATOMIC stuff" really handle Dan's example, tho? >>> A key element in Dan's example if the "ordered singly-linked list", >>> i.e. you need to walk the list an unbounded number of steps until you >>> can find the insertion point, so I don't think you can do the whole >>> thing inside your ATOMIC stuff. >> >> Technically, yes, you can put a search loop in an ATOOMIC event. >> Whether you want to or not is a different story. My example >> illustrated the ATOMIC manipulation of the event without a search. >> >> In addition, if the search it long, code developer should either >> to the search before the event, or grab a Mutex to prevent >> interference during the search and rest of the critical region. > > The problem, as specified, excluded this idea that the list was > long. > > The point was simply to show a scenario where your atomic > operation proposal breaks down, and where you might want to > disable interrupt delivery. The point wasn't to ask whether > the specific problem could be recast in a different way; it > probably can. The question was to ask whether your proposal > could support that specific problem. I don't see how it can. > >>> IOW, you'd have to somehow move the list-walk outside of the atomic >>> section. >> >> Yes, >> >>> E.g. if you know elements are only ever removed from the tail of the >>> list, you can presumably walk the list outside of the ATOMIC stuff and >>> then do the "remove from the queue and insert into the list" atomically >>> since it's a small&finite number of steps (with a test to loop back to >>> the list-walk if someone else inserted or removed anything at that point >>> in the mean time). >> >> Or maintain a tail pointer. > > There's no guarantee that the tail is the correct place to > insert the element, vis the order of the elements. https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 11:20 +0000 |
| Message-ID | <vru3i7$kna$2@reader1.panix.com> |
| In reply to | #111287 |
In article <vrt37r$27c13$4@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 3/24/2025 1:28 PM, Dan Cross wrote: >> In article <96987d473656f296ec63c30626a46730@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >>> On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote: >>> >>>> MitchAlsup1 [2025-03-24 17:36:28] wrote: >>>>> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote: >>>>>> Consider something as simple as popping an item off of the front >>>>>> of a queue and inserting it into an ordered singly-linked list: >>>> [...] >>>>> I have almost that in the documentation for my ATOMIC stuff:: >>>>> The following code moves a doubly linked element from one place >>>>> in a concurrent data structure to another without any interested >>>>> 3rd party being able to see that the element is now within the >>>>> CDS at any time:: >>>> >>>> Would your "ATOMIC stuff" really handle Dan's example, tho? >>>> A key element in Dan's example if the "ordered singly-linked list", >>>> i.e. you need to walk the list an unbounded number of steps until you >>>> can find the insertion point, so I don't think you can do the whole >>>> thing inside your ATOMIC stuff. >>> >>> Technically, yes, you can put a search loop in an ATOOMIC event. >>> Whether you want to or not is a different story. My example >>> illustrated the ATOMIC manipulation of the event without a search. >>> >>> In addition, if the search it long, code developer should either >>> to the search before the event, or grab a Mutex to prevent >>> interference during the search and rest of the critical region. >> >> The problem, as specified, excluded this idea that the list was >> long. >> >> The point was simply to show a scenario where your atomic >> operation proposal breaks down, and where you might want to >> disable interrupt delivery. The point wasn't to ask whether >> the specific problem could be recast in a different way; it >> probably can. The question was to ask whether your proposal >> could support that specific problem. I don't see how it can. >> >>>> IOW, you'd have to somehow move the list-walk outside of the atomic >>>> section. >>> >>> Yes, >>> >>>> E.g. if you know elements are only ever removed from the tail of the >>>> list, you can presumably walk the list outside of the ATOMIC stuff and >>>> then do the "remove from the queue and insert into the list" atomically >>>> since it's a small&finite number of steps (with a test to loop back to >>>> the list-walk if someone else inserted or removed anything at that point >>>> in the mean time). >>> >>> Or maintain a tail pointer. >> >> There's no guarantee that the tail is the correct place to >> insert the element, vis the order of the elements. > >https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html If you go back and review the thread, you'd see that the problem is to remove an element from a queue, and insert it into an ordered list. This part of the discussion is concerning the latter operation. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-25 13:38 -0700 |
| Message-ID | <vrv483$3ekk$2@dont-email.me> |
| In reply to | #111293 |
On 3/25/2025 4:20 AM, Dan Cross wrote: > In article <vrt37r$27c13$4@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 3/24/2025 1:28 PM, Dan Cross wrote: >>> In article <96987d473656f296ec63c30626a46730@www.novabbs.org>, >>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>> On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote: >>>> >>>>> MitchAlsup1 [2025-03-24 17:36:28] wrote: >>>>>> On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote: >>>>>>> Consider something as simple as popping an item off of the front >>>>>>> of a queue and inserting it into an ordered singly-linked list: >>>>> [...] >>>>>> I have almost that in the documentation for my ATOMIC stuff:: >>>>>> The following code moves a doubly linked element from one place >>>>>> in a concurrent data structure to another without any interested >>>>>> 3rd party being able to see that the element is now within the >>>>>> CDS at any time:: >>>>> >>>>> Would your "ATOMIC stuff" really handle Dan's example, tho? >>>>> A key element in Dan's example if the "ordered singly-linked list", >>>>> i.e. you need to walk the list an unbounded number of steps until you >>>>> can find the insertion point, so I don't think you can do the whole >>>>> thing inside your ATOMIC stuff. >>>> >>>> Technically, yes, you can put a search loop in an ATOOMIC event. >>>> Whether you want to or not is a different story. My example >>>> illustrated the ATOMIC manipulation of the event without a search. >>>> >>>> In addition, if the search it long, code developer should either >>>> to the search before the event, or grab a Mutex to prevent >>>> interference during the search and rest of the critical region. >>> >>> The problem, as specified, excluded this idea that the list was >>> long. >>> >>> The point was simply to show a scenario where your atomic >>> operation proposal breaks down, and where you might want to >>> disable interrupt delivery. The point wasn't to ask whether >>> the specific problem could be recast in a different way; it >>> probably can. The question was to ask whether your proposal >>> could support that specific problem. I don't see how it can. >>> >>>>> IOW, you'd have to somehow move the list-walk outside of the atomic >>>>> section. >>>> >>>> Yes, >>>> >>>>> E.g. if you know elements are only ever removed from the tail of the >>>>> list, you can presumably walk the list outside of the ATOMIC stuff and >>>>> then do the "remove from the queue and insert into the list" atomically >>>>> since it's a small&finite number of steps (with a test to loop back to >>>>> the list-walk if someone else inserted or removed anything at that point >>>>> in the mean time). >>>> >>>> Or maintain a tail pointer. >>> >>> There's no guarantee that the tail is the correct place to >>> insert the element, vis the order of the elements. >> >> https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html > > If you go back and review the thread, you'd see that the problem > is to remove an element from a queue, and insert it into an > ordered list. This part of the discussion is concerning the > latter operation. There are lock-free ways to insert into an ordered list, indeed.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 22:21 +0000 |
| Message-ID | <vrva8k$9ka$2@reader1.panix.com> |
| In reply to | #111312 |
In article <vrv483$3ekk$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 3/25/2025 4:20 AM, Dan Cross wrote: >> In article <vrt37r$27c13$4@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 3/24/2025 1:28 PM, Dan Cross wrote: >>>> There's no guarantee that the tail is the correct place to >>>> insert the element, vis the order of the elements. >>> >>> https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html >> >> If you go back and review the thread, you'd see that the problem >> is to remove an element from a queue, and insert it into an >> ordered list. This part of the discussion is concerning the >> latter operation. > >There are lock-free ways to insert into an ordered list, indeed. How is that relevant? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-25 16:23 -0700 |
| Message-ID | <vrvdth$d24n$1@dont-email.me> |
| In reply to | #111315 |
On 3/25/2025 3:21 PM, Dan Cross wrote: > In article <vrv483$3ekk$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 3/25/2025 4:20 AM, Dan Cross wrote: >>> In article <vrt37r$27c13$4@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 3/24/2025 1:28 PM, Dan Cross wrote: >>>>> There's no guarantee that the tail is the correct place to >>>>> insert the element, vis the order of the elements. >>>> >>>> https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html >>> >>> If you go back and review the thread, you'd see that the problem >>> is to remove an element from a queue, and insert it into an >>> ordered list. This part of the discussion is concerning the >>> latter operation. >> >> There are lock-free ways to insert into an ordered list, indeed. > > How is that relevant? inserting into an ordered list is not relevant?
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web