Larrabee delayed: anyone know what's happening?
|
Prev: PEEEEEEP
Next: Texture units as a general function
From: pkhuong on 25 Dec 2009 11:17 In article <jg0d07-mtb.ln1(a)ntp.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > Andy "Krazy" Glew wrote: > > I suspect that there is at least some user level parallel code that > > assumes byte writes are - what is the proper term? Atomic? Non-lossy? > > Not implemented via a non-atomic RMW? > > There might be some such code somewhere, but only by accident, I don't > believe anyone is using it intentionally: You want semaphores to be > separated at least by a cache line if you care about performance, but I > guess it is conceivable some old coder decided to pack all his lock > variables into a single byte range. I believe some software barriers depend on atomic byte-sized writes to adjacent addresses. The goal is to both save some memory and use SWAR when waiting for other threads. Paul Khuong
From: Anne & Lynn Wheeler on 25 Dec 2009 12:18 Bill Todd <billtodd(a)metrocast.net> writes: > When clusters came along (1983) it developed external "Hierarchical > Storage Controllers" (HSCs, using - I think - MSCP extensions) which > could be considered somewhat akin to channel controllers, save that > they were developed not to off-load the host but to facilitate > concurrently sharing the storage they controlled among multiple hosts > (and AFAIK did not allow arbitrary code to be downloaded to execute in > them, though they were intelligent and could independently handle > things like RAID - > including NV mirrored write-back caches and cooperation with other > HSCs - and backup). some part of HSC was to handle out-board locking in shared-disk cluster environment .... something better than (device) reserve/release ... that had been around from (at least) early 360 days. minor reference to doing compare&swap i/o sequence in CKD dasd as alternative (late 70s) http://www.garlic.com/~lynn/2009s.html#29 channels, was Larrabee delayed: anyone know what's happening? early 70s ... the 3830/3330 disk controller had the "ACP" (airline control program) RPQ ... which supported "logical" locking out in the controller (somewhere I think there was reference to 2314 having something similar earlier) ... misc. past posts: http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP http://www.garlic.com/~lynn/2004.html#49 Mainframe not a good architecture for interactive workloads http://www.garlic.com/~lynn/2004.html#50 Mainframe not a good architecture for interactive workloads http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2008i.html#38 American Airlines http://www.garlic.com/~lynn/2008i.html#39 American Airlines http://www.garlic.com/~lynn/2008j.html#50 Another difference between platforms old email on the subject (from Jim Gray to distribution): http://www.garlic.com/~lynn/2009i.html#email800325 above mentions system/r (original relational/sql implementation) .... misc past posts http://www.garlic.com/~lynn/submain.html#systemr when we were doing ha/cmp & ha/cmp scaleup ... misc past posts http://www.garlic.com/~lynn/subtopic.html#hacmp we worked with DBMS vendors that had done implementations for vax/cluster ... and supported vax/cluster lock semantics compatibility interface. however, some of the vendors had lists of things that (vax/cluster) had been done inefficiently (&/or had grown up over decade or so) ... which we had to avoid/fix (some of which related to implementation details based on feature/function provided by HSC) as part of doing HA/CMP ... we were also called into for design walk-thrus for various RAID vendors ... looking for single-point-of-failures (it was interesting the number of vendors that would do the raid semantics for disk ... but completely overlook various single-point-of-failures in other places in the implementation). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 25 Dec 2009 12:21 Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > old email on the subject (from Jim Gray to distribution): > http://www.garlic.com/~lynn/2009i.html#email800325 oops, finger slip http://www.garlic.com/~lynn/2008i.html#email800325 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 25 Dec 2009 12:45 hmy1 <hmy1(a)aol.com> writes: > IBM's System z (lastest mainframe brand name) I/O technology has alot > of value and is an industry standard (T11.org, FC-SB-4). > Just to mention a few differentiators from FCP: i've got lots of old email from the FCS mailing list about all the churn the pok channel engineers were causing ... trying to overlay half-duplex, end-to-end serialized paradigm on top of the underlying full-duplex asynchronous FCS. part of this was escon technology had been laying around pok, unannounced for possibly a decade (but used for mainframe channel paradigm was half-duplex, end-to-end serialization. one of the rs/6000 engineers took it, did some tweaking (which made it incompatible, full-duplex, etc). then he wanted to do a 800mbit version ... and we had been involved in the FCS activity ... and managed to talk him into getting involved with FCS instead. Then the pok channel engineers got involved in standardization activity (not so much on the basic standard .... but trying to overlay stuff on top of the underlying standard). alternative example was the serial copper, full-duplex asynchronous stuff that Hursley did (Harrier/9333) ... with effectively packetized scsi commands. we spent some effort trying to get harrier morphed so that interoperated with FCS ... but in turned into "SSA" instead. referenceed here ... in old post related to ha/cmp & ha/cmp scaleup http://www.garlic.com/~lynn/95.html#13 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Robert Myers on 25 Dec 2009 14:31
On Dec 25, 4:07 am, Bill Todd <billt...(a)metrocast.net> wrote: > Why try to use channel terminology to describe a configuration that > doesn't really fit it? IIRC the XT (ISA) bus didn't support masters > other than the host system: if so, then (at least from the hardware > viewpoint) the host called the shots (as it does in the channel > approach) but also handled the I/O devices (as it does not in the > channel approach). I wanted to elicit as specific an answer as I could, so I used a concrete example. PCI/XT bus devices could do bus mastering, so far as I know, but I'm not sure why it's relevant. It would have been not all that difficult to have intercepted I/O going either way to the 32- bit system and done whatever one cared to with it, so I'm still not sure what a mainframe channel has, other than careful and expensive engineering that pays far more attention to reliability than anything available outside the world of mainframes. Thanks for your explanations, which give me a much clearer picture of the various choices. Robert. |