Itanium had appeal
|
From: Rick Jones on 29 Apr 2010 14:13 Chris Gray <cg(a)graysage.com> wrote: > I/O was done by polling - they could afford a thread doing that > because they had 128 available per chip. What implications would polling have for power consumption? Keeping a thread (or threads probably) going lickety-split checking for I/O completions without unpleasant latency would tend to preclude getting into a nice low-power state wouldn't it? Sure, all the world's supposed to be virtualized now with hardware always running at 80+% utilization anyway or you are an evil person trying to kill the planet, but still... rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: nmm1 on 29 Apr 2010 15:05 In article <hrci7n$hak$2(a)usenet01.boi.hp.com>, Rick Jones <rick.jones2(a)hp.com> wrote: >Chris Gray <cg(a)graysage.com> wrote: >> I/O was done by polling - they could afford a thread doing that >> because they had 128 available per chip. > >What implications would polling have for power consumption? Keeping a >thread (or threads probably) going lickety-split checking for I/O >completions without unpleasant latency would tend to preclude getting >into a nice low-power state wouldn't it? Not if done competently. A simple primitive that says "put me to sleep until event X happens" is what is needed. Regards, Nick Maclaren.
From: Anne & Lynn Wheeler on 29 Apr 2010 15:56 MitchAlsup <MitchAlsup(a)aol.com> writes: > (*) I don't remember the nemonic IBM used that is the equivalent of > DCAS charlie had invented compare&swap when working on fine grain locking on cp67 (CAS was chosen because they are charlie's initials). The initial attempt to get CAS included in 370 was rebuffed ... the favorite son operating system in POK, claiming that test&set was more than sufficient. the challenge give was to come up with non-multiprocessor specific use for compare&swap ... thus was born the descriptions for various application use of atomic instruction ... that continues to show up in principles of operation ... nearly 40yrs later. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320 the actual mnemonics became CS & CDS -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Rick Jones on 29 Apr 2010 17:53 nmm1(a)cam.ac.uk wrote: > In article <hrci7n$hak$2(a)usenet01.boi.hp.com>, > Rick Jones <rick.jones2(a)hp.com> wrote: > >What implications would polling have for power consumption? > >Keeping a thread (or threads probably) going lickety-split checking > >for I/O completions without unpleasant latency would tend to > >preclude getting into a nice low-power state wouldn't it? > Not if done competently. A simple primitive that says "put me to > sleep until event X happens" is what is needed. What would event X be then if not an interrupt or its functional equivalent? rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: nmm1 on 29 Apr 2010 18:14
In article <hrcv4s$nm8$2(a)usenet01.boi.hp.com>, Rick Jones <rick.jones2(a)hp.com> wrote: >> >> >What implications would polling have for power consumption? >> >Keeping a thread (or threads probably) going lickety-split checking >> >for I/O completions without unpleasant latency would tend to >> >preclude getting into a nice low-power state wouldn't it? > >> Not if done competently. A simple primitive that says "put me to >> sleep until event X happens" is what is needed. > >What would event X be then if not an interrupt or its functional >equivalent? A message arriving on a FIFO? A memory location being written to? The problem with interrupts is NOT the execution of the handler, but the effect on the code that is interrupted. Regards, Nick Maclaren. |