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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-01 20:01 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <NCXGP.567737$f81.412324@fx48.iad> |
| In reply to | #111398 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 4/1/2025 8:31 AM, Scott Lurndal wrote: >> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> Scott Lurndal wrote: >> >>>> In the abstract, a thread can be considered a sequence of instructions >>>> executed with a consistent processor state (registers, flags, MMU). >>>> =20 >>>> Threads, using that definition, can be implemented fully in software >>>> (using OS facilities for coordination between entities). User-mode >>>> threads are an example of this, and were implemented in systems that >>>> did not have Operating system support for threads as a schedulable >>>> entity. >>>> =20 >>>> Operating systems later added explicit support for multiple threads >>>> of execution to share a single address space by defining a thread >>>> schedulable entity encapsulating the thread context (general register >>>> state, et alia). POSIX Pthreads was the standard on the Unix side. >>>> =20 >>>> Subsequently, the hardware vendors realized that they could better >>>> utilize the hardware by creating the concept of a 'hardware thread' >>>> where the processor resources for a core could be divvied up and >>>> shared by multiple hardware contexts (Intel called it hyperthreading). >>>> =20 >>> >>> In my programmer world view, a pure user software thread isn't that=20 >>> interesting, it typically allows the programmer to control (more or=20 >>> less) when it can be interrupted. >> >> Using the pre-pthreads posix facilities (signals and getcontext/setcontext) >> to support user-level threads wasn't uncommon. Unix SVR4ES/MP actually had >> both kernel threads (called lightweight processes (LWP)) and user-level >> threads in an M-N setup (M user threads multiplexed on N kernel threads). >> >> Didn't turn out to be particularly useful. > >Are you referring to green threads? Or Fibers? Neither.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-04-01 13:17 -0700 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <vshhl6$3tnbb$3@dont-email.me> |
| In reply to | #111399 |
On 4/1/2025 1:01 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 4/1/2025 8:31 AM, Scott Lurndal wrote: >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>> Scott Lurndal wrote: >>> >>>>> In the abstract, a thread can be considered a sequence of instructions >>>>> executed with a consistent processor state (registers, flags, MMU). >>>>> =20 >>>>> Threads, using that definition, can be implemented fully in software >>>>> (using OS facilities for coordination between entities). User-mode >>>>> threads are an example of this, and were implemented in systems that >>>>> did not have Operating system support for threads as a schedulable >>>>> entity. >>>>> =20 >>>>> Operating systems later added explicit support for multiple threads >>>>> of execution to share a single address space by defining a thread >>>>> schedulable entity encapsulating the thread context (general register >>>>> state, et alia). POSIX Pthreads was the standard on the Unix side. >>>>> =20 >>>>> Subsequently, the hardware vendors realized that they could better >>>>> utilize the hardware by creating the concept of a 'hardware thread' >>>>> where the processor resources for a core could be divvied up and >>>>> shared by multiple hardware contexts (Intel called it hyperthreading). >>>>> =20 >>>> >>>> In my programmer world view, a pure user software thread isn't that=20 >>>> interesting, it typically allows the programmer to control (more or=20 >>>> less) when it can be interrupted. >>> >>> Using the pre-pthreads posix facilities (signals and getcontext/setcontext) >>> to support user-level threads wasn't uncommon. Unix SVR4ES/MP actually had >>> both kernel threads (called lightweight processes (LWP)) and user-level >>> threads in an M-N setup (M user threads multiplexed on N kernel threads). >>> >>> Didn't turn out to be particularly useful. >> >> Are you referring to green threads? Or Fibers? > > Neither. I think we are talking about user threads, ala PThreads, vs kernel "realm" threads... Is that right? This thread is a little confusing from time to time. Actually, here is some source code for WinNT4: https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos Not sure how it got out there, but there it "seems" to be... Actually one time I was experiment with per-cpu data in user space by pinning threads to cores via affinity masks. fun times.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-01 22:04 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <OpZGP.1988024$_N6e.56164@fx17.iad> |
| In reply to | #111400 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 4/1/2025 1:01 PM, Scott Lurndal wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> On 4/1/2025 8:31 AM, Scott Lurndal wrote: >>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>>> Scott Lurndal wrote: >>>> >>>>>> In the abstract, a thread can be considered a sequence of instructions >>>>>> executed with a consistent processor state (registers, flags, MMU). >>>>>> =20 >>>>>> Threads, using that definition, can be implemented fully in software >>>>>> (using OS facilities for coordination between entities). User-mode >>>>>> threads are an example of this, and were implemented in systems that >>>>>> did not have Operating system support for threads as a schedulable >>>>>> entity. >>>>>> =20 >>>>>> Operating systems later added explicit support for multiple threads >>>>>> of execution to share a single address space by defining a thread >>>>>> schedulable entity encapsulating the thread context (general register >>>>>> state, et alia). POSIX Pthreads was the standard on the Unix side. >>>>>> =20 >>>>>> Subsequently, the hardware vendors realized that they could better >>>>>> utilize the hardware by creating the concept of a 'hardware thread' >>>>>> where the processor resources for a core could be divvied up and >>>>>> shared by multiple hardware contexts (Intel called it hyperthreading). >>>>>> =20 >>>>> >>>>> In my programmer world view, a pure user software thread isn't that=20 >>>>> interesting, it typically allows the programmer to control (more or=20 >>>>> less) when it can be interrupted. >>>> >>>> Using the pre-pthreads posix facilities (signals and getcontext/setcontext) >>>> to support user-level threads wasn't uncommon. Unix SVR4ES/MP actually had >>>> both kernel threads (called lightweight processes (LWP)) and user-level >>>> threads in an M-N setup (M user threads multiplexed on N kernel threads). >>>> >>>> Didn't turn out to be particularly useful. >>> >>> Are you referring to green threads? Or Fibers? >> >> Neither. > >I think we are talking about user threads, ala PThreads, vs kernel >"realm" threads... Is that right? https://www.tech-insider.org/unix/research/1992/0720.html https://ieeexplore.ieee.org/document/528923 Here, it's called the many-to-many model. https://docs.oracle.com/cd/E19620-01/805-4031/6j3qv1oej/index.html >https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos The NT4 source code was licensed by Microsoft to other companies.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-04-02 06:25 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <2025Apr2.082556@mips.complang.tuwien.ac.at> |
| In reply to | #111394 |
scott@slp53.sl.home (Scott Lurndal) writes: >Unix SVR4ES/MP actually had >both kernel threads (called lightweight processes (LWP)) and user-level >threads in an M-N setup (M user threads multiplexed on N kernel threads). > >Didn't turn out to be particularly useful. Maybe the SVR4ES/MP stuff was not particularly useful. Combining user-level threads and kernel threads in an M-N setup has turned out to be very useful in, e.g., Erlang applications. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-04-02 13:04 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <vsjclj$mtp$1@reader1.panix.com> |
| In reply to | #111414 |
In article <2025Apr2.082556@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >scott@slp53.sl.home (Scott Lurndal) writes: >>Unix SVR4ES/MP actually had >>both kernel threads (called lightweight processes (LWP)) and user-level >>threads in an M-N setup (M user threads multiplexed on N kernel threads). >> >>Didn't turn out to be particularly useful. > >Maybe the SVR4ES/MP stuff was not particularly useful. Combining >user-level threads and kernel threads in an M-N setup has turned out >to be very useful in, e.g., Erlang applications. It's useful when threads are carefully managed, so that programs can ensure that the set of OS threads is always available so that runnable LWPs can be scheduled onto them. This implies that the OS-managed threads should not block, as if they do, you lose 1/M'th of your parallelism. But the N:M model really breaks down when LWPs become unrunnable in a way that does not involve the user-level thread scheduler, something that can happen in surprising places. For instance, consider Unix/POSIX `open`: from an API perspective this simply maps a symbolic file path name to a file descriptor that can subsequently be used to perform IO on the named file. While it is well-known that the interface is defined so that it can block opening some kinds of devices, for example, some terminal devices until the line is asserted, that is not the usual case, and noteably `open` does no IO on the file itself. So generally, most programs would expect that it has no reason to block. But that's just the interface, the implementation is different. When we observe that the resolution of a name to an FD is always synchronous with respect to the calling program, we can see that there are a number of places where `open` can block in the kernel because it may actually require IO: the path name argument may point into a non-resident part of the address space that needs to be paged into memory. Or the per-component lookups while walking the path may require IO to find the corresponding directory entries in directory files, and so on. POSIX does not provide us an alternative asynchronous `open` call, so if an LWP opens a file, we might lose the OS-managed thread it was running on for a while, if it becomes blocked in the kernel waiting on IO. About the best you can do to detect this kind of blocking is schedule an event to send yourself a signal after some reasonable timeout, and cancel that event if `open` completes before the timeout expires. Furthermore, because LWPs and OS-managed threads are usually independent, their respective schedulers might make pathological decisions with respect to one another. Consider two LWPs that are passing a token back and forth between themselves for some reason; for good throughput, we'd want these gang-scheduled onto OS threads, but they might bounce around running on the available set of OS threads, and if the OS snatched the thread that one was scheduled to while the other was running, throughput would suffer. The problem here is that generally, scheduling decisions made by the LWP scheduler are not knowable to the OS and vice-versa, even though you really want both to cooperate in this case. 1:1 threading models solve all of these problems, at the expense of being heavier-weight. Languages like Erlang and Go do a decent job in an M:N context by enforcing tight control of the language runtime, which handles all of the squirrely details on the program's behalf. A lot of work has been done on M:N: Pysche, Scheduler Activations, `rfork`, upcalls to DECthreads in VMS, etc. More recently, systems like Akaros proposed a different model that punted nearly all scheduling to userspace and adopts something that's more like M:C, where "C" is "cores", by building a virtual-multiprocessor abstraction for many-core processes. http://akaros.org/news.html - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-04-03 16:45 +0200 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <vsm6ul$tmpt$1@dont-email.me> |
| In reply to | #111415 |
Dan Cross wrote: > In article <2025Apr2.082556@mips.complang.tuwien.ac.at>, > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> scott@slp53.sl.home (Scott Lurndal) writes: >>> Unix SVR4ES/MP actually had >>> both kernel threads (called lightweight processes (LWP)) and user-level >>> threads in an M-N setup (M user threads multiplexed on N kernel threads). >>> >>> Didn't turn out to be particularly useful. >> >> Maybe the SVR4ES/MP stuff was not particularly useful. Combining >> user-level threads and kernel threads in an M-N setup has turned out >> to be very useful in, e.g., Erlang applications. > > It's useful when threads are carefully managed, so that programs > can ensure that the set of OS threads is always available so that > runnable LWPs can be scheduled onto them. This implies that the > OS-managed threads should not block, as if they do, you lose > 1/M'th of your parallelism. But the N:M model really breaks > down when LWPs become unrunnable in a way that does not involve > the user-level thread scheduler, something that can happen in > surprising places. > > For instance, consider Unix/POSIX `open`: from an API > perspective this simply maps a symbolic file path name to a file > descriptor that can subsequently be used to perform IO on the > named file. While it is well-known that the interface is > defined so that it can block opening some kinds of devices, for > example, some terminal devices until the line is asserted, that > is not the usual case, and noteably `open` does no IO on the > file itself. So generally, most programs would expect that it > has no reason to block. Pretty much all WIidows machines suffer badly from this, due to the inclusion of realtime/inline virus/malware scanning. A friend of mine/former coworker was part of the team which fixed rustup on windows, basically by treating every single file IO operation as async: It turns out that Windows can indeed maintain more or less the same throughput as Linux on a workload which is heavy on file creation/file write, but each individual operation will suffer from a lot of latency, so it is only by allowing more or less all of them to overlap that the latency cost can be mostly hidden. This was of course not a problem back on MSDOS around 1986, before the first anti-virus software came along. We had zero multi-threading and mostly had to care about making file read/write buffers large enough to sature the disk interface. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-03 15:00 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <FoxHP.1477197$eNx6.766449@fx14.iad> |
| In reply to | #111420 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: >Dan Cross wrote: >> In article <2025Apr2.082556@mips.complang.tuwien.ac.at>, >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> Unix SVR4ES/MP actually had >>>> both kernel threads (called lightweight processes (LWP)) and user-level >>>> threads in an M-N setup (M user threads multiplexed on N kernel threads). >>>> >>>> Didn't turn out to be particularly useful. >>> >>> Maybe the SVR4ES/MP stuff was not particularly useful. Combining >>> user-level threads and kernel threads in an M-N setup has turned out >>> to be very useful in, e.g., Erlang applications. >> >> It's useful when threads are carefully managed, so that programs >> can ensure that the set of OS threads is always available so that >> runnable LWPs can be scheduled onto them. This implies that the >> OS-managed threads should not block, as if they do, you lose >> 1/M'th of your parallelism. But the N:M model really breaks >> down when LWPs become unrunnable in a way that does not involve >> the user-level thread scheduler, something that can happen in >> surprising places. >> >> For instance, consider Unix/POSIX `open`: from an API >> perspective this simply maps a symbolic file path name to a file >> descriptor that can subsequently be used to perform IO on the >> named file. While it is well-known that the interface is >> defined so that it can block opening some kinds of devices, for >> example, some terminal devices until the line is asserted, that >> is not the usual case, and noteably `open` does no IO on the >> file itself. So generally, most programs would expect that it >> has no reason to block. The one case where open was a problem on traditional unix was for line printers. The open of /dev/lp could block if the printer (on a centronics port) was not-ready. And it was an uninterruptable block, even SIGKILL was blocked.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-04-03 17:16 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <vsmfou$9n6$1@reader1.panix.com> |
| In reply to | #111421 |
In article <FoxHP.1477197$eNx6.766449@fx14.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >Dan Cross wrote: >>[snip] >> For instance, consider Unix/POSIX `open`: from an API >> perspective this simply maps a symbolic file path name to a file >> descriptor that can subsequently be used to perform IO on the >> named file. While it is well-known that the interface is >> defined so that it can block opening some kinds of devices, for >> example, some terminal devices until the line is asserted, that >> is not the usual case, and noteably `open` does no IO on the >> file itself. So generally, most programs would expect that it >> has no reason to block. > >The one case where open was a problem on traditional unix was >for line printers. The open of /dev/lp could block if the >printer (on a centronics port) was not-ready. And it was >an uninterruptable block, even SIGKILL was blocked. I'd worry more about, say a pathname that requires traversing NFS for one reason or another (symlinks, or just on a mounted filesystem). Nothing prevents an NFS server from becoming inaccessible during a lookup. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-03 17:24 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <AvzHP.350389$sbY2.343252@fx40.iad> |
| In reply to | #111422 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <FoxHP.1477197$eNx6.766449@fx14.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >>Dan Cross wrote: >>>[snip] >>> For instance, consider Unix/POSIX `open`: from an API >>> perspective this simply maps a symbolic file path name to a file >>> descriptor that can subsequently be used to perform IO on the >>> named file. While it is well-known that the interface is >>> defined so that it can block opening some kinds of devices, for >>> example, some terminal devices until the line is asserted, that >>> is not the usual case, and noteably `open` does no IO on the >>> file itself. So generally, most programs would expect that it >>> has no reason to block. >> >>The one case where open was a problem on traditional unix was >>for line printers. The open of /dev/lp could block if the >>printer (on a centronics port) was not-ready. And it was >>an uninterruptable block, even SIGKILL was blocked. > >I'd worry more about, say a pathname that requires traversing >NFS for one reason or another (symlinks, or just on a mounted >filesystem). Nothing prevents an NFS server from becoming >inaccessible during a lookup. However, you can specify a soft mount rather than a hard mount to resolve that.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-04-04 01:44 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <vsndh4$qn2$1@reader1.panix.com> |
| In reply to | #111424 |
In article <AvzHP.350389$sbY2.343252@fx40.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <FoxHP.1477197$eNx6.766449@fx14.iad>, >>Scott Lurndal <slp53@pacbell.net> wrote: >>>Dan Cross wrote: >>>>[snip] >>>> For instance, consider Unix/POSIX `open`: from an API >>>> perspective this simply maps a symbolic file path name to a file >>>> descriptor that can subsequently be used to perform IO on the >>>> named file. While it is well-known that the interface is >>>> defined so that it can block opening some kinds of devices, for >>>> example, some terminal devices until the line is asserted, that >>>> is not the usual case, and noteably `open` does no IO on the >>>> file itself. So generally, most programs would expect that it >>>> has no reason to block. >>> >>>The one case where open was a problem on traditional unix was >>>for line printers. The open of /dev/lp could block if the >>>printer (on a centronics port) was not-ready. And it was >>>an uninterruptable block, even SIGKILL was blocked. >> >>I'd worry more about, say a pathname that requires traversing >>NFS for one reason or another (symlinks, or just on a mounted >>filesystem). Nothing prevents an NFS server from becoming >>inaccessible during a lookup. > >However, you can specify a soft mount rather than a hard mount >to resolve that. To kill the process, sure. Still kinda sucks, though, from a user experience point of view. :-) - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-04-03 22:22 -0400 |
| Subject | Centronics (was Re: Threads (was Re: MSI interrupts)) |
| Message-ID | <0jeuujhqokmds92u0qpsn4t11bum8rrn77@4ax.com> |
| In reply to | #111421 |
On Thu, 03 Apr 2025 15:00:53 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Terje Mathisen <terje.mathisen@tmsw.no> writes: > >>> For instance, consider Unix/POSIX `open`: from an API >>> perspective this simply maps a symbolic file path name to a file >>> descriptor that can subsequently be used to perform IO on the >>> named file. While it is well-known that the interface is >>> defined so that it can block opening some kinds of devices, for >>> example, some terminal devices until the line is asserted, that >>> is not the usual case, and noteably `open` does no IO on the >>> file itself. So generally, most programs would expect that it >>> has no reason to block. > >The one case where open was a problem on traditional unix was >for line printers. The open of /dev/lp could block if the >printer (on a centronics port) was not-ready. And it was >an uninterruptable block, even SIGKILL was blocked. To be clear: was this an actual Centronics (parallel) port, or just a standard parallel port talking to a printer that uses a Centronics connector? I still have a couple of working laser printers that have Centronics connectors. They talk to standard parallel ports via parallel <-> Centronics cables. They currently are hosted on a Windows machine ... but with the imminent demise of Win10, I plan to move them to Linux. But I don't want software (print/queue daemon?) hanging if a printer happens to be turned off. I have long wanted to retire the parallel ports, but I have never been able to get USB <-> Centronics working reliably: when a printer goes to sleep on USB, it never gets woken up again. I have tried adapters and cables from different vendors, but nothing has worked reliably and I have never been able to determine where the problem lies. No amount of futzing with server-side USB settings seems to help, and there is nothing for it on the printer side other than totally disabling sleep mode.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-04 02:29 +0000 |
| Subject | Re: Centronics (was Re: Threads (was Re: MSI interrupts)) |
| Message-ID | <4uHHP.1485264$eNx6.1191209@fx14.iad> |
| In reply to | #111426 |
George Neuner <gneuner2@comcast.net> writes: >On Thu, 03 Apr 2025 15:00:53 GMT, scott@slp53.sl.home (Scott Lurndal) >wrote: > >>Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >>>> For instance, consider Unix/POSIX `open`: from an API >>>> perspective this simply maps a symbolic file path name to a file >>>> descriptor that can subsequently be used to perform IO on the >>>> named file. While it is well-known that the interface is >>>> defined so that it can block opening some kinds of devices, for >>>> example, some terminal devices until the line is asserted, that >>>> is not the usual case, and noteably `open` does no IO on the >>>> file itself. So generally, most programs would expect that it >>>> has no reason to block. >> >>The one case where open was a problem on traditional unix was >>for line printers. The open of /dev/lp could block if the >>printer (on a centronics port) was not-ready. And it was >>an uninterruptable block, even SIGKILL was blocked. > >To be clear: was this an actual Centronics (parallel) port, or just a >standard parallel port talking to a printer that uses a Centronics >connector? The latter. Would have been late 80's at Convergent Technologies.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-04-03 01:38 -0400 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <fm6sujprvvtaq33pnliab0jl6bofbjvhm9@4ax.com> |
| In reply to | #111393 |
On Tue, 1 Apr 2025 16:44:11 +0200, Terje Mathisen <terje.mathisen@tmsw.no> wrote: >In my programmer world view, a pure user software thread isn't that >interesting, it typically allows the programmer to control (more or >less) when it can be interrupted. Done properly, user space threads can be pre-emptively scheduled and otherwise interrupted. Also, consider "scheduler activations", wherein the kernel provides only virtual cores, and all threading is done in user space. https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf There is an implementation of this idea on NetBSD http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html It's not a terribly popular idea, but IMO it is an interesting one. YMMV. >Terje George
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-04-03 12:15 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <vslu46$esb$1@reader1.panix.com> |
| In reply to | #111416 |
In article <fm6sujprvvtaq33pnliab0jl6bofbjvhm9@4ax.com>, George Neuner <gneuner2@comcast.net> wrote: >On Tue, 1 Apr 2025 16:44:11 +0200, Terje Mathisen ><terje.mathisen@tmsw.no> wrote: > > >>In my programmer world view, a pure user software thread isn't that >>interesting, it typically allows the programmer to control (more or >>less) when it can be interrupted. > >Done properly, user space threads can be pre-emptively scheduled and >otherwise interrupted. This is true, but the details on contemporary machines and operating systems are super intricate. Goroutines can be preemptively scheduled, though, as an example. >Also, consider "scheduler activations", wherein the kernel provides >only virtual cores, and all threading is done in user space. > >https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf >https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf > >There is an implementation of this idea on NetBSD >http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html > > >It's not a terribly popular idea, but IMO it is an interesting one. >YMMV. Scheduler activations was an interesting idea, but came with significant drawbacks. Lack of support for deferring activation events during (user) critical sections and lack of a virtual core abstraction to complement its virtual multiprocessor were probably the biggest. Psyche provided a virtual core abstraction, but not a VMP. Akaros combined the two in a novel way that gave an M:C model, but never got past the research stage. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Robert Swindells <rjs@fdy2.co.uk> |
|---|---|
| Date | 2025-04-04 10:41 +0000 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <vsod18$37c2k$1@dont-email.me> |
| In reply to | #111416 |
On Thu, 03 Apr 2025 01:38:53 -0400, George Neuner wrote: > Also, consider "scheduler activations", wherein the kernel provides only > virtual cores, and all threading is done in user space. > > https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf > https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf > > There is an implementation of this idea on NetBSD > http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html The scheduler activations implementation of threads was removed from NetBSD in 2012.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-04-04 23:10 -0400 |
| Subject | Re: Threads (was Re: MSI interrupts) |
| Message-ID | <dm71vj5mnufn4b2mfmpd0nhu0qetntv7f9@4ax.com> |
| In reply to | #111430 |
On Fri, 4 Apr 2025 10:41:44 -0000 (UTC), Robert Swindells <rjs@fdy2.co.uk> wrote: >On Thu, 03 Apr 2025 01:38:53 -0400, George Neuner wrote: > >> Also, consider "scheduler activations", wherein the kernel provides only >> virtual cores, and all threading is done in user space. >> >> https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf >> https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf >> >> There is an implementation of this idea on NetBSD >> http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html > >The scheduler activations implementation of threads was removed from >NetBSD in 2012. Yes, but it is still available from the archives.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-04-01 10:07 -0400 |
| Message-ID | <WrSGP.1475033$eNx6.441549@fx14.iad> |
| In reply to | #111380 |
Dan Cross wrote:
> In article <tWhGP.1790040$TBhc.304536@fx16.iad>,
> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>> Also Gol91 VAX VMS Internals and Data Structures v5.2 1991
>>
>> All three, Gol91, Gol94, Rus12 have a section on spinlocks and
>> explicitly say spinlocks synchronize processors, not threads.
>>
>> Gol91 pg 172, Gol94 pg 254: "A spinlock is acquired by a processor to
>> synchronize access to data shared by members of an SMP system."
>
> Also [Gol91], page 173:
>
> |A resource synchronized through elevated IPL on a uniprocessor
> |is synchronzied through a combination of spinlock and elevated
> |IPL on an SMP system. *A thread of execution* running on one
> |processor acquires a spinlock to serialized access to the data
> |with *threads of execution* running on other processors.
> |Before acquiring, the _thread of execution_ raises IPL to block
> |accesses *by other threads of execution* running on the *same*
> |processor.
>
> Emphasis added. Note that the primitives that do the acquiring
> and holding are threads.
>
> (Note, I already quoted this text from [Gol94] in an earlier
> response; page 255.)
And I've tried to get you to stop treating the terms "thread of execution"
and "kernel thread" as equivalent. They are not.
It says "thread of execution" which as I have explained is not a
necessarily a kernel thread (or in this case a VMS process).
It could be an interrupt or a Dpc, or code triggered as a consequence
of actions of any of those which has no connection to whichever
random kernel thread was running on a processor at that time.
All of those "threads of execution" could acquire a spinlock at their
associated IPL but only one of those is due to the current kernel thread.
Even if that was a kernel thread that raised its IPL and performed
some kernel action, when it tries to lower its IPL < dispatch,
that can trigger the Dispatcher which may invoke the Scheduler
and ThreadSwitcher. As that transition into Dispatcher might trigger
a thread switch, it conceptually[1] dumps its thread register context
in case a switch is needed.
And all of those consequences which were not directly invoked by the
current kernel thread but were triggered by it could acquire spinlocks.
Those triggered "threads of execution" were set up by other
"threads of execution", some of which may be kernel threads,
but are unrelated to the currently executing kernel thread.
On entry to the Dispatcher, the register set, the thread of execution,
conceptually[1] is no longer connected to whichever kernel thread
was running on the processor. The private processor state information
maintains a reference to its current kernel thread whose context will be
restored when it exits the Dispatcher.
[1] I say conceptually because with careful layering of the code for
entering and leaving the Dispatcher/Scheduler/ThreadSwitcher the OS
can defer saving some of the kernel thread's registers into the kernel
thread context until the actual thread switch occurs, as long as it
does not modify those registers. x64 FPU or SIMD registers might be examples.
>> Rus12 pg 179: "The mechanism the kernel uses to achieve multiprocessor
>> mutual exclusion is called a spinlock."
>
> Yes, I already pointed out that this is the usual case. But you
> are still ignoring the uniprocessor case: spinlocks must work
> there, as well.
>
> But more relevantly, this does not imply that _processors_ "own"
> spinlocks in the way you have asserted. That is done by
> threads. A thread does not magically "turn into" a processor
> when it acquires a spinlock; it remains a thread, albeit one
> that is now holding a spinlock that it wasn't before.
I've pointed you at the sections of those books which repeatedly refers to
them as "processor spinlocks". Rus12 on pg 181 even shows a WNT kernel
debugger command in "EXPERIMENT: Viewing Global Queued Spinlocks" which
*displays a list of queued spinlocks held by each processor*.
That list is stored in the Processor Control Region PCR,
a per-processor status block WNT maintains.
If that is not enough to convince you, nothing will.
I've tried my best to explain it and pointed you to the text that supports
this but you remain unconvinced and this is just going around in circles
and using up both of our time. As your interpretation works for you and
mine works for me, we'll just have to agree to disagree.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-04-01 17:39 +0000 |
| Message-ID | <vsh8bk$per$1@reader1.panix.com> |
| In reply to | #111392 |
In article <WrSGP.1475033$eNx6.441549@fx14.iad>, EricP <ThatWouldBeTelling@thevillage.com> wrote: >Dan Cross wrote: >> In article <tWhGP.1790040$TBhc.304536@fx16.iad>, >> EricP <ThatWouldBeTelling@thevillage.com> wrote: >>> Also Gol91 VAX VMS Internals and Data Structures v5.2 1991 >>> >>> All three, Gol91, Gol94, Rus12 have a section on spinlocks and >>> explicitly say spinlocks synchronize processors, not threads. >>> >>> Gol91 pg 172, Gol94 pg 254: "A spinlock is acquired by a processor to >>> synchronize access to data shared by members of an SMP system." >> >> Also [Gol91], page 173: >> >> |A resource synchronized through elevated IPL on a uniprocessor >> |is synchronzied through a combination of spinlock and elevated >> |IPL on an SMP system. *A thread of execution* running on one >> |processor acquires a spinlock to serialized access to the data >> |with *threads of execution* running on other processors. >> |Before acquiring, the _thread of execution_ raises IPL to block >> |accesses *by other threads of execution* running on the *same* >> |processor. >> >> Emphasis added. Note that the primitives that do the acquiring >> and holding are threads. >> >> (Note, I already quoted this text from [Gol94] in an earlier >> response; page 255.) > >And I've tried to get you to stop treating the terms "thread of execution" >and "kernel thread" as equivalent. They are not. Yes, and what I've tried to explain to you, over and over, is that in this context it really doesn't matter. A "kernel thread" *can run in kernel mode*. >It says "thread of execution" which as I have explained is not a >necessarily a kernel thread (or in this case a VMS process). This is well-known. It is also irrelevant. A processor, or core, or whatever, is simply not a "thread of execution"; it is the thing that "threads of execution" run on. You are trying to ascribe to a physical object the attributes of a logical entity. >It could be an interrupt or a Dpc, or code triggered as a consequence >of actions of any of those which has no connection to whichever >random kernel thread was running on a processor at that time. > >All of those "threads of execution" could acquire a spinlock at their >associated IPL but only one of those is due to the current kernel thread. Oh, I see your confusion. The thing you seem to be missing is that all of those "threads of execution" _are running in the kernel in the context of some software thread_. Those software threads is the entity that owns a spinlock when it's acquired. In the case of Windows, VMS, etc, usually that's some "kernel thread", while it is is running in the kernel, but I would not be surprised if they had other kinds of dedicated software threads they used only in the kernel for special purposes. >Even if that was a kernel thread that raised its IPL and performed >some kernel action, when it tries to lower its IPL < dispatch, >that can trigger the Dispatcher which may invoke the Scheduler >and ThreadSwitcher. As that transition into Dispatcher might trigger >a thread switch, it conceptually[1] dumps its thread register context >in case a switch is needed. > >And all of those consequences which were not directly invoked by the >current kernel thread but were triggered by it could acquire spinlocks. >Those triggered "threads of execution" were set up by other >"threads of execution", some of which may be kernel threads, >but are unrelated to the currently executing kernel thread. > >On entry to the Dispatcher, the register set, the thread of execution, >conceptually[1] is no longer connected to whichever kernel thread >was running on the processor. The private processor state information >maintains a reference to its current kernel thread whose context will be >restored when it exits the Dispatcher. > >[1] I say conceptually because with careful layering of the code for >entering and leaving the Dispatcher/Scheduler/ThreadSwitcher the OS >can defer saving some of the kernel thread's registers into the kernel >thread context until the actual thread switch occurs, as long as it >does not modify those registers. x64 FPU or SIMD registers might be examples. I'm sorry, I think you're confused here in a similar manner to how you were confused about the way system calls work. >>> Rus12 pg 179: "The mechanism the kernel uses to achieve multiprocessor >>> mutual exclusion is called a spinlock." >> >> Yes, I already pointed out that this is the usual case. But you >> are still ignoring the uniprocessor case: spinlocks must work >> there, as well. >> >> But more relevantly, this does not imply that _processors_ "own" >> spinlocks in the way you have asserted. That is done by >> threads. A thread does not magically "turn into" a processor >> when it acquires a spinlock; it remains a thread, albeit one >> that is now holding a spinlock that it wasn't before. > >I've pointed you at the sections of those books which repeatedly refers to >them as "processor spinlocks". No, you really didn't. You did point to things in the book that appeared to agree with you, but you cherry-picked those and ignored the larger context, where it invariably meant something else that _disagreed_ with your interpretation. Furthermore, you ignored anything that didn't already fit your preconception of how these things fit together. >Rus12 on pg 181 even shows a WNT kernel >debugger command in "EXPERIMENT: Viewing Global Queued Spinlocks" which > *displays a list of queued spinlocks held by each processor*. >That list is stored in the Processor Control Region PCR, >a per-processor status block WNT maintains. > >If that is not enough to convince you, nothing will. Here is another example of cherry-picking out of context. The reference here is to queuing spin locks, where Windows tries to avoid scalability collapse due to cache-coherency overhead when threads running on different processors race on acquiring a heavily contended (spin)lock. The context is obvious in when one considers the surrounding text in addition to that sentence fragment: they are clearly talking about concurrent threads running on different processors racing in parallel. As an aisde, I already pointed to a paper about th topic of non-scalable locks in the context of Linux (Boyd-Wickizer et al): http://pdos.csail.mit.edu/papers/linux:lock.pdf >I've tried my best to explain it and pointed you to the text that supports >this but you remain unconvinced and this is just going around in circles >and using up both of our time. As your interpretation works for you and >mine works for me, we'll just have to agree to disagree. Probably for the best. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-19 23:28 +0000 |
| Message-ID | <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org> |
| In reply to | #111226 |
On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote:
> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>,
> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>I want to address the elephant in the room::
>>
>>Why disable interrupts AT ALL !!
>
> So that you can have some mechanism for building critical
> sections that span multiple instructions, where just having
> access to atomics and spin locks isn't enough.
For what kinds of activities are these critical sections ??
For example, I can schedule a DPC/sofIRQ without using a critical
section (and so can even user threads without privilege, given
the MMU allows). So, we need to dive through the "rest of the
available mechanics" -- keyword available !
There are mechanisms available that readers may not be aware of
or quite grasp how a feature can be used.
So it comes back to:: For what kinds of activities are these
critical sections ?? We know about DPC/softIRQs, we know
about atomic events around core scheduling, and inter-{thread,
process, core} communication. Others ?
>>When running at any privilege, do you not want to accept an interrupt
>>at higher priority with as little delay as possible ??
>
> Usually the assumption is that the critical section is short; a
> handful of instructions, perhaps, so that the cost of blocking a
> high priority interrupt is low.
I think you are talking about critical sections that are not allowed
to fail or be interfered with:: Yes ?
>>Does Interrupt Disable help in this goal ??
>
> This is predicated on an incomplete view of the situation and
> the intersection between hardware and software. Serving high
> priority interrupts quickly is not the only consideration.
>
>>Is there a SANE way to avoid disabling of interrupts ??
>
> It depends on your definition of "sane" in this context. One
> may imagine redesigning all of a system's locking primitives,
> perhaps, to avoid the need to block interrupts in most cases.
> But that pushes a lot of complexity onto software for dubious
> benefit, and even then, it's not clear to me that they can be
> blocked in _all_ cases.
>
> - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-20 12:50 +0000 |
| Message-ID | <vrh2u1$8vn$2@reader1.panix.com> |
| In reply to | #111238 |
In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote:
>
>> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>>I want to address the elephant in the room::
>>>
>>>Why disable interrupts AT ALL !!
>>
>> So that you can have some mechanism for building critical
>> sections that span multiple instructions, where just having
>> access to atomics and spin locks isn't enough.
>
>For what kinds of activities are these critical sections ??
Perhaps modifying the interrupt handlers themselves. Maybe
resetting a stack. If you know that you're not in a place where
you can reasonably save the state associated with taking an
interrupt, you should disable interrupts.
>For example, I can schedule a DPC/sofIRQ without using a critical
>section (and so can even user threads without privilege, given
>the MMU allows). So, we need to dive through the "rest of the
>available mechanics" -- keyword available !
For that one case. Perhaps there are others where a DPC-style
mechanism (not mechanic) is not appropriate.
>There are mechanisms available that readers may not be aware of
>or quite grasp how a feature can be used.
Indeed.
>So it comes back to:: For what kinds of activities are these
>critical sections ?? We know about DPC/softIRQs, we know
>about atomic events around core scheduling, and inter-{thread,
>process, core} communication. Others ?
Booting the system, before interrupt handlers have been
established.
>>>When running at any privilege, do you not want to accept an interrupt
>>>at higher priority with as little delay as possible ??
>>
>> Usually the assumption is that the critical section is short; a
>> handful of instructions, perhaps, so that the cost of blocking a
>> high priority interrupt is low.
>
>I think you are talking about critical sections that are not allowed
>to fail or be interfered with:: Yes ?
Yup.
But let me turn it around, what real-world problem does this
interrupt prioritization scheme solve coupled with the inability
to disable interrupts solve? Is anyone complaining that the
ability to disable interrupts is somehow a serious burden?
- Dan C.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.arch
csiph-web