From: Rick Jones on
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
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
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
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
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.