Crossfire wrote:
O Plameras was once rumoured to have said:
James Gregory wrote:
On Wed, 2005-12-21 at 16:40 +1100, O Plameras wrote:
#define spin_lock_init(lock) do { (void)(lock); } while(0)
#define _raw_spin_lock(lock) do { (void)(lock); } while(0)
I am reading this cited macros. This is very very clear.
It is very very clear what it says, and, i.e., regardless of what
is the value of 'lock' the kernel should do nothing.
That's exactly right. And if you compile without CONFIG_SMP, that's what
gets built into your kernel. You can get away with it because of the
clever way in which a CPU does one thing at a time; there is no "true"
parallelism.
By the way, is it not true that 'pipelining' that's a feature of x86
CPU's starting with i586 which I have pointed out in one of my
previous post is (another name) implementation of 'parallel'
processing ? This means that more than one instructions may be
executed in one clock cycle. This is implemented by using a bus
interface unit (BIU) and an execution unit. Experts on Intel Arch
may confirm the truthfullness or falsehood of this assertion. (I'm
not an expert, I just know by researching).
Yes, but the mild 'parallelism' achieved by pipelining doesn't
actually introduce any concurrency issues - pipelining has very
predictable outcomes, and operations are pretty much guarnateed to be
in-step.
Precisely, pipelining has this feature that two operations are
implemented concurrently.
These two operations are: "code execution" as well "code fetching and
decoding" of the
next instruction at the same time (in same or one cycle - I take it to
mean you understand why I use clock
cycle when I speak of concurrent code execution. One poster as you
probably saw in his post
does'nt). Performance achieve by pipelining is quite significant since
twice more codes
are processed in one clock cycle. If we have the right number of
hardware then we get
about twice more performance than in a CPU without pipelining.
Its nowhere near as unpredictable as having multiple CPUs operating on
the same chunk of memory which is what the SMP lock mechanisms are
intended to guard.
I was talking about pipelining and parallelism. I agree that Pipelining is
NOT the same as SMP. I was talking of pipeling as parallel operations.
I also agree that SMP with two or more CPUs will further improve
performance.
Everyone has no problem with this assertion.
It is also not true parallelism - the concurrection exectuion only
follows a single instance of code, and can only take place with good
scheduling of instructions as not all instructions can be concurrently
executed due to the limited number of execution units in any given
chip -- not all instructions necessarily require the same amount of
on-chip resources to execute.
To me, 'true parallelism' implies concurrent, independant, execution
of code - which is most definately not the case in pipelined
processors. (hell, its not even the case in HT processors).
You are talking about parallel operations in two or more CPUs and I was
specifically talking about parallel operations of codes in CPUs supporting
pipelining in my post.
O Plameras
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
