Re: [SLUG] Re: pentium M series

[O Plameras]

Ian Howson wrote:




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 ?  




So, in this way there is true parallelism in x86 arch.



Holy shit! You are s off base here its not funny. 'More than one
thing per clock cycle' -> What do clock cycles have to do with
parallelism? Nothing. Concurrency means 'concurrent'. If two operations
complete in one clock cycle *in series*, then its not parallel. Its
fast, but not parallel.




Have a look at the intel documentation on Intel IA-32 Architecture - 
Series x86. You

will be pleasantly surprise.



Just about every CPU in existence is pipelined. It's an implementation 
technique, nothing more. It doesn't change the programmer-visible 
model of the CPU, which is a machine which will execute instructions 
one at time. The programmer doesn't have to change their software to 
account for various pipelining structures. As far as the programmer is 
concerned, instructions go through one at a time, in order.



This is one source for my information:

http://academic.eng.au.edu/ce3105/ArtofAssembly/CH03/CH03-3.html#HEADING3-192

According to the above

Pipelining(  http://en.wikipedia.org/wiki/Pipelining) first appeared on 
the 80486 but with no superscalar operation

(http://en.wikipedia.org/wiki/Superscalar).

Pipelining with superscalar operation first appeared on 80686 (This is 
also often referred to as i586+).


It is  pipelining combined with superscalar operation that makes a 
single CPU chip executes
appropriate multiple instructions in a parallel sense.  I think the 
misunderstanding was that I
did not mention supercalar. If an CPU instruction requires 1 clock 
cycle,  with pipelining
and superscalar, in 1 clock cycle (which is a linear time scale the 
duration of which is dependent
on the clock speed of the CPU, e.g. 1.5GHZ has shorter clock cycle that 
1.0GHZ CPU)  it is

possible to implement multiples of these instructions .

Patterson and Hennessy's "Computer Organisation and Design" covers 
this pretty well in chapter 5, "The Processor: Datapath and Control".


Most discussion around parallelism nowadays is with the aim of 
increasing total application performance by adding processing units. 



True. But I was responding to a comment as follows:


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.


Parallelism is not a desirable attribute on its own. The parallelism 
you refer to within the CPU manifests itself as greater CPU 
performance (more instructions executed per unit of time). Using 
multiple CPUs together to achieve greater aggregate performance is a 
fairly difficult problem nowadays due to the interactions between 
threads, and is most definitely programmer-visible (despite what Intel 
and Sony will assert in their marketing material).



I have no issues with the idea that as far as the impact on throughput 
is concerned most users are concerned with parallel computing

using multiple CPUs.

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

Re: [SLUG] Re: pentium M series

[Tom Massey]

* Del <[EMAIL PROTECTED]> [2005-12-26 00:00]:
> I get home from 14 hours solid fishing, boozing, and eating
> to collapse in front of the TV and maybe browse some web
> comics, and my mailbox is full of this?

Ah, some people like to fish, some people like to eat turkey, some
people like to discuss clock cycles. Myself, I like to drink brandy
while playing guitar for the gathering of peoples that seem to show
up here. (Ob Linux - I usually play some music through xmms and play
with the visualisation plugins) It's all good. Why complain? Let people
do what they like. If talking on Slug about Pentium M's is what they
want to do, then why stop them?

> To steal a very famous quote -- all of you:  "Have you ever
> kissed a girl?"

Yes. Um. Sorry, but that's a really evil quotation that should be discarded.

Tom
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Erik de Castro Lopo]

O Plameras wrote:

> The whole point of my original post is that clock cycle is a basic 
> measure of performance in that the shorter it is, the faster (execute
> more instructions per unit time) is the throughput (performance).
> Another way of saying this is in a particular Intel CPU family the
> bigger the MHZ the faster is the CPU.

Ok, here where the disconnect is.

I would be happy to say that "if all other things are equal, there
is a direct relationship between clock speed and performance".

However all other things are not always equal. Performance can
be affected by memory and bus latency, cache sizes, pipeline depth 
and other factors.

Whenever any of these other factors come into play, your statement:

Clock cycles has everything to do in the analysis of CPUs. It 
is the basic measure of CPU performance.

will be misleading and in some cases wrong.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"There are only two things wrong with C++: The initial concept and
the implementation." -- Bertrand Meyer
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Del]

You guys have nothing better to do all day xmas day than to
argue about intel CPUs and clock cycles?

I get home from 14 hours solid fishing, boozing, and eating
to collapse in front of the TV and maybe browse some web
comics, and my mailbox is full of this?

To steal a very famous quote -- all of you:  "Have you ever
kissed a girl?"

--
Del
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[James Gregory]

On Sun, 2005-12-25 at 09:34 +1100, O Plameras wrote:
> 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 ?

I suppose I wasn't entirely clear here. The precise kind of parallelism
I was referring to was concurrent threads of execution. The kind that
requires locking (as you may have inferred from the context).

Just about every CPU I can think of implements some form of
'pipelining', and it's good friends 'super-scalar, out-of-order
execution'. There is an important distinction between these
optimisations and using explicit threads: the former is invisible to the
programmer.

My statement wasn't entirely true, CPUs do many things simoultaneously,
and of import, they can perform a very limited number of instructions in
parallel. But, in addition to evaluating these numerous instructions
concurrently, they are also ensuring that at the other end, it all looks
like it happened serially, but very, very fast.

It's kinda interesting actually, the chip looks ahead some number of
instructions and will identify groups of instructions that don't have
dependencies on each others' outcomes. It then tries to fit those sets
of instructions to the various bits of silicon in the chip (for example,
the integer add unit and the floating-point divide unit will (almost
certainly) be different bits of silicon), those operations will be
performed concurrently and since they are all independent (no one of
this group depends on another's outcome), it won't make any difference.
That's where the all-important "instruction re-ordering" comes in; the
compiler must try to order instructions to make it possible for the CPU
to identify such groups of instructions.

Note however that isomorphic re-orderings of code will have no effect on
the outcome of executing it, so are somewhat irrelevant to a discussion
of locking.

> 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).

There's a heap of 'units', dude. Modern CPUs are insane.

> With pipelining,  the CPU overlaps instruction fetching and decoding with
> instruction execution, i.e., while one instruction is executing BIU is 
> fetching
> and decoding the next instruction. So, assuming you're willing to add 
> hardware
> you can execute more and more operations in parallel.

Yes and no. I suppose you could construct a chip whose explicit purpose
is "to pipeline", but that's not really why hardware engineers started
doing it. It's more about making the most of the silicon you've got. You
don't want bits of silicon (that cost money) to be sitting there idle.
Pipelining just lets you make sure that more of your silicon is busy
more of the time.

> So, in this way there is true parallelism in x86 arch.

I suppose it's a matter of interpretation. It was extremely intentional
that I chose to refer to the type of parallelism in UP-x86 as bereft of
"true parallelism". You can of course choose to interpret those words
however you will. Having made explicit exactly what level of parallelism
UP-x86 provides, the only really important thing to realise is that it
is not a sufficient level of parallelism as to have any effect on
locking. UP kernels don't crash because they don't have locking. They
would if they had what I have referred to as "true parallelism". I'll
happily adopt another term for it if you can suggest a better one.

Merrily,

James.


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Erik de Castro Lopo wrote:


So, looking for wiggle room?
 



What do you mean  by this ?



O Plameras wrote:

 

So, what is 'clock cycle' in your definition ? 
   



My defintion like yours is irrelevant. However, a generally accepted 
definition is here:


  http://en.wikipedia.org/wiki/Clock_cycle

 



As it relates to (Intel)CPU see this:

http://www.google.com/search?hl=en&lr=&oi=defmore&defl=en&q=define:clock+cycle

As you can see, clock cycle is the time it takes to execute the simple 
instruction set.



This definition is crucial  if we want to
compare apples-with-apples. How does it relate to CPU speed ?
   



There is no direct relationship. 

 



This is totally wrong.  There is a direct relationship.

The relationship is that an Intel Pentium 4 with 1.5GHZ has a CPU that 
can execute
1.5 billion intructions in one second if all of these instructions are 
simple instructions.
Another way of saying this is that Pentium 4 - 1.5GHZ has 1.5 billion 
clock cycles.

Some program codes need 1 clock cycles and others need more. With pipelining
1 clock cycle can handle more than 1 instructions.

But since not all instructions are simple, some instructions takes more 
clock cycle
than others. A program will always have a mix of instructions from the 
simple to

somewhat more complex.


And how do you measure CPU performance ?
   



I think performance benchmarks are the best measure of CPU
performance.

 


And remember, I was talking x86 CPU family and not AMD.
   



Have a look at this article:

  http://techreport.com/reviews/2001q3/piii-1.2/index.x?pg=1

On the third page:

But the Pentium 4's deeply pipelined design can't deliver the
same performance, clock for clock, that the Athlon or Pentium 
III can.


Ignore the Athlon for the moment, but notice how the review is
comparing Pentium 4 with Pentium III, both members of the x86
family.
 



Going back to your example in a previous post comparing Intel (2000MHZ) 
and AMD(1400MHZ) CPU's is obviously wrong.


First, Intel and AMD do not have the same instruction sets.

Secondly, the simple Intel instruction is simpler than AMD's(i suspect), 
meaning AMD's
simple instruction does more things that that Intel(I suspect) and their 
architecture are

not similar as to have a meaningful comparison.

So, that is why you cannot compare Intel and AMD.

The whole point of my original post is that clock cycle is a basic 
measure of
performance in that the shorter it is, the faster (execute more 
instructions per unit
time) is the throughput (performance). Another way of saying this is in 
a particular

Intel CPU family the bigger the MHZ the faster is the CPU.

So, to be a good programmer one has to understand these.


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

Re: [SLUG] Re: pentium M series

[Erik de Castro Lopo]

Erik de Castro Lopo wrote:

> Have a look at this article:
> 
>http://techreport.com/reviews/2001q3/piii-1.2/index.x?pg=1
> 
> On the third page:
> 
>  But the Pentium 4's deeply pipelined design can't deliver the
>  same performance, clock for clock, that the Athlon or Pentium 
>  III can.
> 
> Ignore the Athlon for the moment, but notice how the review is
> comparing Pentium 4 with Pentium III, both members of the x86
> family.

Even better, have a look at the graphs on page 5:

http://techreport.com/reviews/2001q3/piii-1.2/index.x?pg=5

Ignore the first two memory bandwidth tests, because the PIII and
P4 have different bus interfaces,  but look at the the third graph
titled "linpack performance". In that graph, compare the 1.2 Ghz
Pentium III with the 1.4GHz Pentium4 for matrix sizes of 255 and
below. Do you see how the 1.2 GHz PIII beats the 1.4GHz P4?

Interesting isn't it?

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"Well behaved women rarely make history." -- Dorothy Parker
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Erik de Castro Lopo]

So, looking for wiggle room?


O Plameras wrote:

> So, what is 'clock cycle' in your definition ? 

My defintion like yours is irrelevant. However, a generally accepted 
definition is here:

   http://en.wikipedia.org/wiki/Clock_cycle

> This definition is crucial  if we want to
> compare apples-with-apples. How does it relate to CPU speed ?

There is no direct relationship. 

> And how do you measure CPU performance ?

I think performance benchmarks are the best measure of CPU
performance.

> And remember, I was talking x86 CPU family and not AMD.

Have a look at this article:

   http://techreport.com/reviews/2001q3/piii-1.2/index.x?pg=1

On the third page:

 But the Pentium 4's deeply pipelined design can't deliver the
 same performance, clock for clock, that the Athlon or Pentium 
 III can.

Ignore the Athlon for the moment, but notice how the review is
comparing Pentium 4 with Pentium III, both members of the x86
family.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"Projects promoting programming in natural language are intrinsically
doomed to fail." -- Edsger Dijkstra
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


These are excuses.
   



Yeah, right!

How about articles like this:

   http://www.tomshardware.com/2001/08/29/hot_microprocessor_news/index.html

which states:

   We've now reached a clock difference of 600 MHz between Intel's 2 GHz 
   Pentium 4 and AMD's 1.4 GHz Athlon processor. It's tough to convince 
   unknowing customers that 1400 is the same as 2000.


and later:

   "AMD's Athlon is often faster than Pentium 4 even though it runs at a lower
   clock!"

I think you need to realise that many people have published statements
that directly contradict your statement:

   Clock cycles has everything to do in the analysis of CPUs. It is the 
   basic measure of CPU performance.


If Intel has ever made a statement that supports your view then show us
so we can bring this issue up with consumer affairs.
 



So, what is 'clock cycle' in your definition ? This definition is 
crucial  if we want to

compare apples-with-apples. How does it relate to CPU speed ?

And how do you measure CPU performance ?

And remember, I was talking x86 CPU family and not AMD.

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

Re: [SLUG] Re: pentium M series

[Erik de Castro Lopo]

O Plameras wrote:

> These are excuses.

Yeah, right!

How about articles like this:

http://www.tomshardware.com/2001/08/29/hot_microprocessor_news/index.html

which states:

We've now reached a clock difference of 600 MHz between Intel's 2 GHz 
Pentium 4 and AMD's 1.4 GHz Athlon processor. It's tough to convince 
unknowing customers that 1400 is the same as 2000.

and later:

"AMD's Athlon is often faster than Pentium 4 even though it runs at a lower
clock!"

I think you need to realise that many people have published statements
that directly contradict your statement:

Clock cycles has everything to do in the analysis of CPUs. It is the 
basic measure of CPU performance.

If Intel has ever made a statement that supports your view then show us
so we can bring this issue up with consumer affairs.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"I could never learn to use C++, because of the completely 
overwhelming desire to redesign the language every time I tried 
to use it, but this is the normal, healthy reaction to C++."
-- Erik Naggum
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 

What did intel say about clock cycle ? What did Intel say about CPU 
performance ?


You can't say "different" when you have'nt disclose what you think they 
said.
   



What I think Intel said and what you think Intel said is irrelevant.
The only thing that matters is what Intel has in fact said.

I have read my fair share of Intel docs over the years and nothing I
have ever read comes anywhere near:

 

Clock cycles has everything to do in the analysis of CPUs. It is the 
basic measure of CPU performance.
   



If you can find anything near that in the Intel docs I want to
see it.

 



These are excuses.

How can you compare when you CAB say what I said but you
CANNOT point out what you think intel says in terms of what clock cycle 
is and

what is the measure of CPU performance.

You have no basis to say what you said in the first place.

Typically troll.


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

Re: [SLUG] Re: pentium M series

[Erik de Castro Lopo]

O Plameras wrote:

> What did intel say about clock cycle ? What did Intel say about CPU 
> performance ?
> 
> You can't say "different" when you have'nt disclose what you think they 
> said.

What I think Intel said and what you think Intel said is irrelevant.
The only thing that matters is what Intel has in fact said.

I have read my fair share of Intel docs over the years and nothing I
have ever read comes anywhere near:

> Clock cycles has everything to do in the analysis of CPUs. It is the 
> basic measure of CPU performance.

If you can find anything near that in the Intel docs I want to
see it.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"life is too long to know C++ well" -- Erik Naggum
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


What am I saying in your own words ?
   



I'll use your words. You said:

   Clock cycles has everything to do in the analysis of CPUs. It is the 
   basic measure of CPU performance.


 



Exactly.


What do you think Intel say ?
   



I don't think Intel has said anything anywhere near what you said.

 



What did intel say about clock cycle ? What did Intel say about CPU 
performance ?


You can't say "different" when you have'nt disclose what you think they 
said.


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

Re: [SLUG] Re: pentium M series

[Erik de Castro Lopo]

O Plameras wrote:

> What am I saying in your own words ?

I'll use your words. You said:

Clock cycles has everything to do in the analysis of CPUs. It is the 
basic measure of CPU performance.

> What do you think Intel say ?

I don't think Intel has said anything anywhere near what you said.


Erik
-- 
+---+
  Erik de Castro Lopo
+---+
Question #10342: Ruling on a Muslim eating with a kaafir
http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=10342&dgn=4
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


This has everything to do with clariyfing
what Intel says and my understanding as to what they are telling us 
users of their CPUs.
   



I suspect that what Intel says and what you understand of what they
say has little if any overlap.
 



What am I saying in your own words ?

What do you think Intel say ?

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

Re: [SLUG] Re: pentium M series

[Erik de Castro Lopo]

O Plameras wrote:

>  This has everything to do with clariyfing
> what Intel says and my understanding as to what they are telling us 
> users of their CPUs.

I suspect that what Intel says and what you understand of what they
say has little if any overlap.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"C++ is a language strongly optimized for liars and people who 
go by guesswork and ignorance." -- Erik Naggum
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Crossfire wrote:


O Plameras was once rumoured to have said:
 


Robert Collins wrote:
   


Holy shit! You are s off base here its not funny. 'More than one
thing per clock cycle' -> What do clock cycles have to do with
parallelism? Nothing. 
 


Clock cycles has everything to do in the analysis of CPUs. It is the
basic measure of CPU performance.
   



Wrong.  The basic measure of performance is the time required to
complete an operation, not the length of a clock cycle.  Clock rate
and operation speed are very orthogonal things.

 



I will not try to convince you otherwise. I am repeating what I know from
Intel documentations.


In fact you'd be a lot better as a programmer if you do understand
clock cycles. For example, codes expend clock cycles when data are
moved around memory; no clock cycles are expended when data are
moved around certain registers.  In this view, you'd learn what
codes in C to avoid and what codes to use.
   



Actuallly, he knows better than you do.
 

Is it not true what I am asserting above ? You have no explanation just 
a personal

and 'cowboy' observation.

I am repeating what I know from Intel documentations. And this has 
nothing to do

with comparing you or him or me. This has everything to do with clariyfing
what Intel says and my understanding as to what they are telling us 
users of their

CPUs. You have your own ideas; good luck with your ideas.


10 years ago, most machines couldn't even fetch data from L1 cache in
a single clock cycle -- some of the earier PPCs were a good exception
there, but the x86 certainly was not a fast machine when it comes to
average cycles per op.

 



This is not an explanation of clock cycle as far as CPU performance.



(I can't speak for now - nor do I care to - but I'd be amazed if intel
has mysteriously revamped their processor to complete all operations
in a single cycle though - all of a sudden, all the collected x86
optimisation technique would go to waste).

 



Aha !  So you have'nt perused the x86 documentations. Strongly recommend you
do and let us know your understanding.

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

Re: [SLUG] Re: pentium M series

[Crossfire]

O Plameras was once rumoured to have said:
> Robert Collins wrote:
>> Holy shit! You are s off base here its not funny. 'More than one
>> thing per clock cycle' -> What do clock cycles have to do with
>> parallelism? Nothing. 
> 
> Clock cycles has everything to do in the analysis of CPUs. It is the
> basic measure of CPU performance.

Wrong.  The basic measure of performance is the time required to
complete an operation, not the length of a clock cycle.  Clock rate
and operation speed are very orthogonal things.

> In fact you'd be a lot better as a programmer if you do understand
> clock cycles. For example, codes expend clock cycles when data are
> moved around memory; no clock cycles are expended when data are
> moved around certain registers.  In this view, you'd learn what
> codes in C to avoid and what codes to use.

Actuallly, he knows better than you do.

10 years ago, most machines couldn't even fetch data from L1 cache in
a single clock cycle -- some of the earier PPCs were a good exception
there, but the x86 certainly was not a fast machine when it comes to
average cycles per op.

(I can't speak for now - nor do I care to - but I'd be amazed if intel
has mysteriously revamped their processor to complete all operations
in a single cycle though - all of a sudden, all the collected x86
optimisation technique would go to waste).

C.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Ian Howson]

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 ?  



So, in this way there is true parallelism in x86 arch.


Holy shit! You are s off base here its not funny. 'More than one
thing per clock cycle' -> What do clock cycles have to do with
parallelism? Nothing. Concurrency means 'concurrent'. If two operations
complete in one clock cycle *in series*, then its not parallel. Its
fast, but not parallel.



Have a look at the intel documentation on Intel IA-32 Architecture - 
Series x86. You

will be pleasantly surprise.


Just about every CPU in existence is pipelined. It's an implementation 
technique, nothing more. It doesn't change the programmer-visible model 
of the CPU, which is a machine which will execute instructions one at 
time. The programmer doesn't have to change their software to account 
for various pipelining structures. As far as the programmer is 
concerned, instructions go through one at a time, in order.


Patterson and Hennessy's "Computer Organisation and Design" covers this 
pretty well in chapter 5, "The Processor: Datapath and Control".


Most discussion around parallelism nowadays is with the aim of 
increasing total application performance by adding processing units. 
Parallelism is not a desirable attribute on its own. The parallelism you 
refer to within the CPU manifests itself as greater CPU performance 
(more instructions executed per unit of time). Using multiple CPUs 
together to achieve greater aggregate performance is a fairly difficult 
problem nowadays due to the interactions between threads, and is most 
definitely programmer-visible (despite what Intel and Sony will assert 
in their marketing material).


Ian

(not a CPU engineer, but I play one on TV)

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Robert Collins wrote:


On Sun, 2005-12-25 at 09:34 +1100, O Plameras wrote:
 


James Gregory wrote:

   


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).


With pipelining,  the CPU overlaps instruction fetching and decoding with
instruction execution, i.e., while one instruction is executing BIU is 
fetching
and decoding the next instruction. So, assuming you're willing to add 
hardware

you can execute more and more operations in parallel.

So, in this way there is true parallelism in x86 arch.

Just a clarification.
   



Holy shit! You are s off base here its not funny. 'More than one
thing per clock cycle' -> What do clock cycles have to do with
parallelism? Nothing. 



Clock cycles has everything to do in the analysis of CPUs. It is the 
basic measure

of CPU performance.

In fact you'd be a lot better as a programmer if you do understand clock 
cycles. For

example,  codes expend clock cycles when data are moved around memory; no
clock cycles are expended when data are moved around certain registers. 
In this

view, you'd learn what codes in C to avoid and what codes to use.


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

Re: [SLUG] Re: pentium M series

[O Plameras]

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

Re: [SLUG] Re: pentium M series

[O Plameras]

Robert Collins wrote:


On Sun, 2005-12-25 at 09:34 +1100, O Plameras wrote:
 


James Gregory wrote:

   


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).


With pipelining,  the CPU overlaps instruction fetching and decoding with
instruction execution, i.e., while one instruction is executing BIU is 
fetching
and decoding the next instruction. So, assuming you're willing to add 
hardware

you can execute more and more operations in parallel.

So, in this way there is true parallelism in x86 arch.

Just a clarification.
   



Holy shit! You are s off base here its not funny. 'More than one
thing per clock cycle' -> What do clock cycles have to do with
parallelism? Nothing. Concurrency means 'concurrent'. If two operations
complete in one clock cycle *in series*, then its not parallel. Its
fast, but not parallel.
 



Have a look at the intel documentation on Intel IA-32 Architecture - 
Series x86. You

will be pleasantly surprise.


If you want an cpu architecture that performs *concurrent operations* in
one cpu, look into EPIC or IA-64.

Just a un-clarification.

Rob


 



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Robert Collins]

On Sun, 2005-12-25 at 09:34 +1100, O Plameras wrote:
> James Gregory wrote:
> 
> >
> >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).
> 
> With pipelining,  the CPU overlaps instruction fetching and decoding with
> instruction execution, i.e., while one instruction is executing BIU is 
> fetching
> and decoding the next instruction. So, assuming you're willing to add 
> hardware
> you can execute more and more operations in parallel.
> 
> So, in this way there is true parallelism in x86 arch.
> 
> Just a clarification.

Holy shit! You are s off base here its not funny. 'More than one
thing per clock cycle' -> What do clock cycles have to do with
parallelism? Nothing. Concurrency means 'concurrent'. If two operations
complete in one clock cycle *in series*, then its not parallel. Its
fast, but not parallel.

If you want an cpu architecture that performs *concurrent operations* in
one cpu, look into EPIC or IA-64.

Just a un-clarification.

Rob


-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Crossfire]

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.

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.

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).

C.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

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).


With pipelining,  the CPU overlaps instruction fetching and decoding with
instruction execution, i.e., while one instruction is executing BIU is 
fetching
and decoding the next instruction. So, assuming you're willing to add 
hardware

you can execute more and more operations in parallel.

So, in this way there is true parallelism in x86 arch.

Just a clarification.

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

Re: UP/SMP switcheroo [Was: [SLUG] Re: pentium M series]

[Anand Kumria]

On Tue, Dec 20, 2005 at 01:51:12PM +1100, Jeff Waugh wrote:
> 
> 
> > Right. Which is what I've found too. Which led me to wondering: Jeff: how
> > do you plan to do this UP/SMP kernel efficiently?
> 
> Ben Collins (our kernel maintainer) forward ported an old 2.4 patch and put
> it in our git repository - maintained on kernel.org -> WE ROCK! It switches
> locks to noops at boot time. It's not 100%, and definitely in dapper atm as
> early stage testing rather than an intent to ship.

Are you talking about Gerd Knorr's SMP alternatives patch, or something
else?



Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

James Gregory wrote:


On Wed, 2005-12-21 at 17:58 +1100, O Plameras wrote:
 


Spinlock is shown for UP.

What is spinlock for SMP ?
   



I omitted it because there's substantially more code to do it. The short
answer (which I'm only half sure of, I'm sure someone else here can
confirm or deny my allegations) is that it disables pre-emption, takes
out a bus lock and does all the standard stuff. It's a binary semaphore,
as per Dijkstra's original formulation of it.

Here's a wikipedia article on semaphores:

   http://en.wikipedia.org/wiki/Semaphore_%28programming%29

Here's the obscure assembly code that does the hard work:

   #define spin_lock_string \
   "\n1:\t" \
   "lock ; decb %0\n\t" \
   "jns 3f\n" \
   "2:\t" \
   "rep;nop\n\t" \
   "cmpb $0,%0\n\t" \
   "jle 2b\n\t" \
   "jmp 1b\n" \
   "3:\n\t"

which you'll find in include/asm-i386/spinlock.h.

 



Thanks, James.

I appreciate that.

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

Re: [SLUG] Re: pentium M series

[O Plameras]

Benno wrote:


On Wed Dec 21, 2005 at 17:57:36 +1100, O Plameras wrote:
 


Benno wrote:

   


On Wed Dec 21, 2005 at 17:35:43 +1100, O Plameras wrote:


 

It seems to me, that this argument is becoming about "you said these and 
I said
these" but NOTHING about what really matters and that is how Ubuntu 
implement SMP.


To me,then, this is not about me or you, what I said and what you said; 
this is about what Ubunto

does as far as SMP is concerned.

You are saying that the previous posts are about what Ubunto does when 
implementing UP.


So, what about what Ubunto does when it implements SMP ?

 

   


From Jeff's post:
   

 


1) Ubuntu currently ships and supports separate packages for UP and SMP
kernels
 

   

Is there something more to the question than that? They have the normal 
kernel
source and compile it twice, once UP, once SMP. It then ships a package 
for each

of these.

Or is the question about how the Linux *kernel* implement SMP?


 


It was shown what spinlock is for UP.

What is spinlock for SMP ?

   





So you are asking how the Linux *kernel* implements SMP. This has nothing
to do with Ubuntu.

I'm sure you can look this up in the kernel code yourself. The place to 
start looking is in include/linux/spinlock.h, and include/asm-i386/spinlock.h


It isn't really worth spamming the whole list with the obtuse x86 assembler.
 



Um.  I'll figure.

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

Re: [SLUG] Re: pentium M series

[O Plameras]

Andrew Bennetts wrote:


O Plameras wrote:
 


Andrew Bennetts wrote:
   


O Plameras wrote:
[...]

 


So, what about what Ubunto does when it implements SMP ?
   


What part of this is unclear:
 


[...]
 


Spinlock is shown for UP.

What is spinlock for SMP ?
   



I don't know what this question has to do with Ubuntu, but anyway...

You can browse the kernel source at http://lxr.linux.no/.  If you search for
"spin_lock_init", you'll see this page:
http://lxr.linux.no/ident?i=spin_lock_init, which gives links to all the various
definitions of that identifier in the source.

The ones you seem to be interested in are in include/linux/spinlock.h:

 - http://lxr.linux.no/source/include/linux/spinlock.h#L104
 - http://lxr.linux.no/source/include/linux/spinlock.h#L211

If I misunderstood your question, please let me know and I'll try to clarify.
 




I see.

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

Re: [SLUG] Re: pentium M series

[James Gregory]

On Wed, 2005-12-21 at 17:58 +1100, O Plameras wrote:
> Spinlock is shown for UP.
> 
> What is spinlock for SMP ?

I omitted it because there's substantially more code to do it. The short
answer (which I'm only half sure of, I'm sure someone else here can
confirm or deny my allegations) is that it disables pre-emption, takes
out a bus lock and does all the standard stuff. It's a binary semaphore,
as per Dijkstra's original formulation of it.

Here's a wikipedia article on semaphores:

http://en.wikipedia.org/wiki/Semaphore_%28programming%29

Here's the obscure assembly code that does the hard work:

#define spin_lock_string \
"\n1:\t" \
"lock ; decb %0\n\t" \
"jns 3f\n" \
"2:\t" \
"rep;nop\n\t" \
"cmpb $0,%0\n\t" \
"jle 2b\n\t" \
"jmp 1b\n" \
"3:\n\t"

which you'll find in include/asm-i386/spinlock.h.

HTH,

James.


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Andrew Bennetts]

O Plameras wrote:
> Andrew Bennetts wrote:
> >O Plameras wrote:
> >[...]
> >
> >>So, what about what Ubunto does when it implements SMP ?
> >
> >What part of this is unclear:
[...]
> 
> Spinlock is shown for UP.
> 
> What is spinlock for SMP ?

I don't know what this question has to do with Ubuntu, but anyway...

You can browse the kernel source at http://lxr.linux.no/.  If you search for
"spin_lock_init", you'll see this page:
http://lxr.linux.no/ident?i=spin_lock_init, which gives links to all the various
definitions of that identifier in the source.

The ones you seem to be interested in are in include/linux/spinlock.h:

  - http://lxr.linux.no/source/include/linux/spinlock.h#L104
  - http://lxr.linux.no/source/include/linux/spinlock.h#L211

If I misunderstood your question, please let me know and I'll try to clarify.

-Andrew.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Benno]

On Wed Dec 21, 2005 at 17:57:36 +1100, O Plameras wrote:
>Benno wrote:
>
>>On Wed Dec 21, 2005 at 17:35:43 +1100, O Plameras wrote:
>> 
>>
>>>It seems to me, that this argument is becoming about "you said these and 
>>>I said
>>>these" but NOTHING about what really matters and that is how Ubuntu 
>>>implement SMP.
>>>
>>>To me,then, this is not about me or you, what I said and what you said; 
>>>this is about what Ubunto
>>>does as far as SMP is concerned.
>>>
>>>You are saying that the previous posts are about what Ubunto does when 
>>>implementing UP.
>>>
>>>So, what about what Ubunto does when it implements SMP ?
>>>
>>>   
>>>
>>
>>From Jeff's post:
>> 
>>
>>>1) Ubuntu currently ships and supports separate packages for UP and SMP
>>> kernels
>>>   
>>>
>>
>>Is there something more to the question than that? They have the normal 
>>kernel
>>source and compile it twice, once UP, once SMP. It then ships a package 
>>for each
>>of these.
>>
>>Or is the question about how the Linux *kernel* implement SMP?
>> 
>>
>
>
>It was shown what spinlock is for UP.
>
>What is spinlock for SMP ?
>



So you are asking how the Linux *kernel* implements SMP. This has nothing
to do with Ubuntu.

I'm sure you can look this up in the kernel code yourself. The place to 
start looking is in include/linux/spinlock.h, and include/asm-i386/spinlock.h

It isn't really worth spamming the whole list with the obtuse x86 assembler.

Cheers,

Benno
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Andrew Bennetts wrote:


O Plameras wrote:
[...]
 


So, what about what Ubunto does when it implements SMP ?
   



What part of this is unclear:

 



Spinlock is shown for UP.

What is spinlock for SMP ?


Jeff Waugh wrote:

   


Let's be clear:

1) Ubuntu currently ships and supports separate packages for UP and SMP
 kernels

2) Ubuntu is experimenting with (in the developer branch) a patch that will
 dynamically optimise out the SMP locks on UP systems, thus allowing us
 to build only one kernel package for both UP and SMP systems
 



?

-Andrew.

 



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Benno wrote:


On Wed Dec 21, 2005 at 17:35:43 +1100, O Plameras wrote:
 

It seems to me, that this argument is becoming about "you said these and 
I said
these" but NOTHING about what really matters and that is how Ubuntu 
implement SMP.


To me,then, this is not about me or you, what I said and what you said; 
this is about what Ubunto

does as far as SMP is concerned.

You are saying that the previous posts are about what Ubunto does when 
implementing UP.


So, what about what Ubunto does when it implements SMP ?

   



From Jeff's post:
 


1) Ubuntu currently ships and supports separate packages for UP and SMP
 kernels
   



Is there something more to the question than that? They have the normal kernel
source and compile it twice, once UP, once SMP. It then ships a package for each
of these.

Or is the question about how the Linux *kernel* implement SMP?
 




It was shown what spinlock is for UP.

What is spinlock for SMP ?

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

Re: [SLUG] Re: pentium M series

[O Plameras]

Jeff Waugh wrote:




 


So, what about what Ubunto does when it implements SMP ?
   



By reading my reply, you would have found:

 


Let's be clear:

1) Ubuntu currently ships and supports separate packages for UP and SMP
  kernels
 



Ta-da.

 



What does this mean ?


- Jeff

 



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jamie Wilkinson]

This one time, at band camp, O Plameras wrote:
>
>It seems to me, that this argument is becoming about "you said these and 
>I said
>these" but NOTHING about what really matters and that is how Ubuntu 
>implement SMP.
>
>To me,then, this is not about me or you, what I said and what you said; 
>this is about what Ubunto
>does as far as SMP is concerned.
>
>You are saying that the previous posts are about what Ubunto does when 
>implementing UP.
>
>So, what about what Ubunto does when it implements SMP ?

I have five ubuntoes on my ubunfoot.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Andrew Bennetts]

O Plameras wrote:
[...]
> 
> So, what about what Ubunto does when it implements SMP ?

What part of this is unclear:

> Jeff Waugh wrote:
> 
> >Let's be clear:
> >
> >1) Ubuntu currently ships and supports separate packages for UP and SMP
> >   kernels
> >
> >2) Ubuntu is experimenting with (in the developer branch) a patch that will
> >   dynamically optimise out the SMP locks on UP systems, thus allowing us
> >   to build only one kernel package for both UP and SMP systems

?

-Andrew.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Benno]

On Wed Dec 21, 2005 at 17:35:43 +1100, O Plameras wrote:
>
>It seems to me, that this argument is becoming about "you said these and 
>I said
>these" but NOTHING about what really matters and that is how Ubuntu 
>implement SMP.
>
>To me,then, this is not about me or you, what I said and what you said; 
>this is about what Ubunto
>does as far as SMP is concerned.
>
>You are saying that the previous posts are about what Ubunto does when 
>implementing UP.
>
>So, what about what Ubunto does when it implements SMP ?
>

From Jeff's post:
>1) Ubuntu currently ships and supports separate packages for UP and SMP
>   kernels

Is there something more to the question than that? They have the normal kernel
source and compile it twice, once UP, once SMP. It then ships a package for each
of these.

Or is the question about how the Linux *kernel* implement SMP?

Benno
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> So, what about what Ubunto does when it implements SMP ?

By reading my reply, you would have found:

> > Let's be clear:
> >
> > 1) Ubuntu currently ships and supports separate packages for UP and SMP
> >kernels

Ta-da.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
   "People who paid for bug fixes in the 3c501 driver also bought MacIIfx
  support contracts..." - Alan Cox
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

It seems to me, that this argument is becoming about "you said these and 
I said
these" but NOTHING about what really matters and that is how Ubuntu 
implement SMP.


To me,then, this is not about me or you, what I said and what you said; 
this is about what Ubunto

does as far as SMP is concerned.

You are saying that the previous posts are about what Ubunto does when 
implementing UP.


So, what about what Ubunto does when it implements SMP ?

O Plameras

Jeff Waugh wrote:




 


Someone should explain how this is done in your kernel.
   



No, James asked how we did the dynamic enable/disable of the SMP locks,
which is an entirely different thing to the existence of separate kernel
builds for UP and SMP (which you incorrectly assumed, based on no apparent
research or attention to detail in this very thread whatsoever, that Ubuntu
did not ship).

 


You were asked by one poster  but you sidestep the question. And until
now, there is no sensible explanation.
   



I did not sidestep the question about dynamic enable/disable of the SMP
locks. Sure, I did not explain it in depth, but James understood what we
were trying.

 


Just saying I have no research is not true. I have and I explained my
understanding.
   



You quoted two lines out of context (the comment would have helped you) to
assert that a) Ubuntu didn't ship an SMP kernel package and b) that Linux
did not support SMP (given that these two lines are direct quotes from the
kernel, Ubuntu or not).

Let's be clear:

1) Ubuntu currently ships and supports separate packages for UP and SMP
   kernels

2) Ubuntu is experimenting with (in the developer branch) a patch that will
   dynamically optimise out the SMP locks on UP systems, thus allowing us
   to build only one kernel package for both UP and SMP systems

3) Linux absolutely supports SMP, and your interpretation of the quoted
   code was wrong, mostly because you missed a crucial part of the original
   quote, but probably also because you seem to be incorrectly attributing
   this code to the Ubuntu dynamic UP/SMP patch (probably just confusion on
   your part)

- Jeff

 



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> Someone should explain how this is done in your kernel.

No, James asked how we did the dynamic enable/disable of the SMP locks,
which is an entirely different thing to the existence of separate kernel
builds for UP and SMP (which you incorrectly assumed, based on no apparent
research or attention to detail in this very thread whatsoever, that Ubuntu
did not ship).

> You were asked by one poster  but you sidestep the question. And until
> now, there is no sensible explanation.

I did not sidestep the question about dynamic enable/disable of the SMP
locks. Sure, I did not explain it in depth, but James understood what we
were trying.

> Just saying I have no research is not true. I have and I explained my
> understanding.

You quoted two lines out of context (the comment would have helped you) to
assert that a) Ubuntu didn't ship an SMP kernel package and b) that Linux
did not support SMP (given that these two lines are direct quotes from the
kernel, Ubuntu or not).

Let's be clear:

 1) Ubuntu currently ships and supports separate packages for UP and SMP
kernels

 2) Ubuntu is experimenting with (in the developer branch) a patch that will
dynamically optimise out the SMP locks on UP systems, thus allowing us
to build only one kernel package for both UP and SMP systems

 3) Linux absolutely supports SMP, and your interpretation of the quoted
code was wrong, mostly because you missed a crucial part of the original
quote, but probably also because you seem to be incorrectly attributing
this code to the Ubuntu dynamic UP/SMP patch (probably just confusion on
your part)

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
  "We are not complete muppets." - Murray Cumming
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[James Gregory]

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.

If you compile *with* CONFIG_SMP, those definitions get preprocessed out
and some other macros get compiled in that do things like disable
interrupts, bus lock and do atomic writes and so forth, with the net
effect of implementing a spin lock.

If you install the -smp kernel on Ubuntu today, you get the version
compiled *with* CONFIG_SMP, and the code I cited will be compiled out
and substituted with this devious spin-lock implementing spin lock code.

Otherwise you don't, and (unsurprisingly) you get UP support, with no
spin locks, which you've verified for us with your insightful analysis
of those macros.

Jeff explained that right now Ubuntu ships only with the non-CONFIG_SMP
kernel on the CD due to space constraints *and* that subsequent releases
of Ubuntu have a solution to this UP/SMP problem in a single kernel
image. If I understand correctly, it's implemented with some runtime
function-table rewriting, which means you would only incur the cost of a
function call, rather than the bus-lock etc.

I hope that's clear.

James.


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Jeff Waugh 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.
   



*Completely* out of context and without any research or understanding of the
kernel internals, I can see why you might think that.
 




Someone should explain how this is done in your kernel. You were asked 
by one
poster  but you sidestep the question. And until now, there is no 
sensible explanation.
Just saying I have no research is not true. I have and I explained my 
understanding.



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

Re: [SLUG] Re: pentium M series

[Dean Hamstead]

its a mailing list... its only slightly better than a web forum.

the main improvement is that no one has anime-p0rn avatars.

Dean

Benno wrote:

On Wed Dec 21, 2005 at 16:47:26 +1100, Jeff Waugh 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.


*Completely* out of context and without any research or understanding of the
kernel internals, I can see why you might think that.




Of course the whole quote started with a "#ifndef SMP" and a comment
explaining exactly what it was doing.


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Benno]

On Wed Dec 21, 2005 at 16:47:26 +1100, Jeff Waugh 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.
>
>*Completely* out of context and without any research or understanding of the
>kernel internals, I can see why you might think that.
>

Of course the whole quote started with a "#ifndef SMP" and a comment
explaining exactly what it was doing.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> i think debian is linux at its finest. go team.

So do I/we -> couldn't/wouldn't build Ubuntu on anything else - the Original
Enterprise Linux.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
  "Creative thinkers make many false starts, and continually waver
   between unmanageable fantasies and systematic attack." - Harry Hepner
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> #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.

*Completely* out of context and without any research or understanding of the
kernel internals, I can see why you might think that.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
"A computer with a bullet in it is just a paperweight, A map with a
  bullet in it is still a map." - Maj. Keith Hauk
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jamie Wilkinson]

This one time, at band camp, Dean Hamstead wrote:
>is there any way you could have the installer detect the number of cpus?

Yes, Red Hat (and by extension, Fedora) installer does this and makes sure
you have the smp package installed and set up to boot first if you've got
more than one CPU.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> is there any way you could have the installer detect the number of cpus?
> 
> perhaps do the install with an SMP kernel. then if there is more than one
> cpu install the smp, if not install the uniprocessor kernel

That's precisely what the debian-installer infrastructure does, *if* there
are multiple kernel packages available on the CD. Our server profile CD will
do that, because we can make room for all the packages, but we can't fit all
of it on the usual desktop CD.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
 "I have a burning curiosity about everything, everything-- except
   country and western, of course." - David Bowie
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Jeff Waugh wrote:




 


Just confirming you don't.
   



Perhaps you read the list about as carefully as you write your emails. *In
this very thread* I mentioned our experimentation with dynamically enabling
and disabling the SMP locks, thus allowing us to ship a single package that
supports both UP and SMP *instead of two packages*.
 



#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.

I would have written this to say, as an illustration,

If lock = 0, do nothing;
if lock = 1, do shared-mem-1;
if lock = 2,  do shared-mem-2;
if lock = 3,  do sem;
etc.

Now,  because it is written the way it is, I figured out
SMP cannot be implemented because spinlock macro
does nothing and in this situation you will have what
you are trying to avoid a  "WiggleSplatBingoKernel"
when SMP is implemented.

Hope this clarifies.


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

Re: [SLUG] Re: pentium M series

[Dean Hamstead]

is there any way you could have the installer detect the number of cpus?

perhaps do the install with an SMP kernel. then if there is more than
one cpu install the smp, if not install the uniprocessor kernel

*shrug*

but im actually a fan of seperate kernel packages.
nor do i use ubuntu. i think debian is linux at its finest.
go team.

Dean

Jeff Waugh wrote:




Just confirming you don't.



Perhaps you read the list about as carefully as you write your emails. *In
this very thread* I mentioned our experimentation with dynamically enabling
and disabling the SMP locks, thus allowing us to ship a single package that
supports both UP and SMP *instead of two packages*.

- Jeff



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Peter Hardy]

On Wed, 2005-12-21 at 16:07 +1100, Jeff Waugh wrote:
> 
> 
> > >#define spin_lock_init(lock)do { (void)(lock); } while(0)
> > >#define _raw_spin_lock(lock)do { (void)(lock); } while(0)
> > 
> > Is this euphemism for "in ubuntu SMP  is not implemented" ?
> 
> *boggle* Dude. Seriously. We ship Linux, not WiggleSplatBingoKernel.

The next time my computer goes *wiggle*splat*bingo*, I'll think of you.

-- 
Pete

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> Just confirming you don't.

Perhaps you read the list about as carefully as you write your emails. *In
this very thread* I mentioned our experimentation with dynamically enabling
and disabling the SMP locks, thus allowing us to ship a single package that
supports both UP and SMP *instead of two packages*.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
 "Building a Kernel is a requirement for Securing Servers." - Oscar
  Plameras
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Jeff Waugh wrote:




 


#define spin_lock_init(lock)do { (void)(lock); } while(0)
#define _raw_spin_lock(lock)do { (void)(lock); } while(0)
 


Is this euphemism for "in ubuntu SMP  is not implemented" ?
   



*boggle* Dude. Seriously. We ship Linux, not WiggleSplatBingoKernel.
 




Just confirming you don't.

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

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> >#define spin_lock_init(lock)do { (void)(lock); } while(0)
> >#define _raw_spin_lock(lock)do { (void)(lock); } while(0)
> 
> Is this euphemism for "in ubuntu SMP  is not implemented" ?

*boggle* Dude. Seriously. We ship Linux, not WiggleSplatBingoKernel.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
  It's not a disease, it's an occupation!
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[James Gregory]

On Wed, 2005-12-21 at 15:23 +1100, O Plameras wrote:
> James Gregory wrote:
> 
> >/*
> > * If CONFIG_SMP is unset, declare the _raw_* definitions as nops
> > */
> >#define spin_lock_init(lock)do { (void)(lock); } while(0)
> >#define _raw_spin_lock(lock)do { (void)(lock); } while(0)
> >
> >  
> >
> 
> Is this euphemism for "in ubuntu SMP  is not implemented" ?

The piece of code I was citing comes from a region protected by 

#ifndef CONFIG_SMP

And as I noted, the equivalent region which is compiled in when
CONFIG_SMP *is* set, actually implements a spin lock.

So I suppose you could think of it as a euphemism for "when SMP is
disabled, SMP is disabled".

James.


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

James Gregory wrote:


/*
* If CONFIG_SMP is unset, declare the _raw_* definitions as nops
*/
#define spin_lock_init(lock)do { (void)(lock); } while(0)
#define _raw_spin_lock(lock)do { (void)(lock); } while(0)

 



Is this euphemism for "in ubuntu SMP  is not implemented" ?

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

Re: [SLUG] Re: pentium M series

[Ian Wienand]

On Tue, Dec 20, 2005 at 02:06:11AM +, Dave Airlie wrote:
> I've heard chat on lkml about using alternatives (the kernel ones) to do
> this.. basically at build time you construct a table of every spinlock
> call and patch them all up at CPU hotplug or kernel boot time...
> 
> Sounds like magic to me...

No more magic than a debugger inserting breakpoints, but the thin end
of a fairly nasty wedge -- debugging the kernel is already hard enough
without ever being able to ascertain exactly what is executing!

-i


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Benno]

On Tue Dec 20, 2005 at 02:06:11 +, Dave Airlie wrote:
>>
>> Right. Which is what I've found too. Which led me to wondering: Jeff:
>> how do you plan to do this UP/SMP kernel efficiently? The kernel
>> implements spin_lock as a macro that gets compiled out when building for
>> UP:
>
>I've heard chat on lkml about using alternatives (the kernel ones) to do
>this.. basically at build time you construct a table of every spinlock
>call and patch them all up at CPU hotplug or kernel boot time...
>
>Sounds like magic to me...

Right, the boot time binary rewriting is a pretty cool way of diong
this. This is also what we did with afterburning work, which allowed
you to have one kernel that can be run on hardware and on top of
L4, Xen or UML.

Cheers,

Benno
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

UP/SMP switcheroo [Was: [SLUG] Re: pentium M series]

[Jeff Waugh]

> Right. Which is what I've found too. Which led me to wondering: Jeff: how
> do you plan to do this UP/SMP kernel efficiently?

Ben Collins (our kernel maintainer) forward ported an old 2.4 patch and put
it in our git repository - maintained on kernel.org -> WE ROCK! It switches
locks to noops at boot time. It's not 100%, and definitely in dapper atm as
early stage testing rather than an intent to ship.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
   "Blessed are the cracked, for they let in the light." - Spike Milligan
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Dave Airlie]

>
> Right. Which is what I've found too. Which led me to wondering: Jeff:
> how do you plan to do this UP/SMP kernel efficiently? The kernel
> implements spin_lock as a macro that gets compiled out when building for
> UP:

I've heard chat on lkml about using alternatives (the kernel ones) to do
this.. basically at build time you construct a table of every spinlock
call and patch them all up at CPU hotplug or kernel boot time...

Sounds like magic to me...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[James Gregory]

On Mon, 2005-12-19 at 14:40 +1100, Ian Wienand wrote:
> Mostly I think the sub-architecture is passed via different flags to
> gcc, which can try to optimise the code.  Talking with people from SGI
> who look into that sort of thing, the benefits of even a much better
> compiler fall into noise compared to things like lock contention. 

Right. Which is what I've found too. Which led me to wondering: Jeff:
how do you plan to do this UP/SMP kernel efficiently? The kernel
implements spin_lock as a macro that gets compiled out when building for
UP:

/*
 * If CONFIG_SMP is unset, declare the _raw_* definitions as nops
 */
#define spin_lock_init(lock)do { (void)(lock); } while(0)
#define _raw_spin_lock(lock)do { (void)(lock); } while(0)

(from include/linux/spinlock.h on 2.6.10)

(the first line is not so exciting, but the second one is pretty
important).

The corresponding code for when CONFIG_SMP is set actually implements a
spin lock, along with all the consequences you'd expect.

Does Ubuntu have a magical solution to this, or do you just execute the
extra code on UP?

Yours,

Curious in Woolloomoolloo.


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Hal Ashburner wrote:


On Mon, 2005-12-19 at 23:40 +1100, Crossfire wrote:
 


The 'correct' method to test for MMX (and later extensions) is to
check the output of the CPUID instruction.  (Introduced in the late
486 families - guaranteed to be available on all Pentium class or
newer systems however.)  It is the CPUID instruction that the linux
kernel uses to generate most of the information in /proc/cpuinfo on
i386 systems.
   



cpuid is awesome!
http://www.livejournal.com/users/kernelslacker/31732.html
 



A small C code to check if MMX is supported in your Linux System (x86 
CPU not AMD64).


#include 
int mmx_init__(void)
{
   int MMX__;
   __asm__ __volatile__ (
   "movl $1, %%eax\n\t"
   "cpuid\n\t"
   "andl $0x80, %%edx\n\t"
   "movl %%edx, %0"
   : "=q" (MMX__)
   );
   return MMX__;
}

int main(void)
{
   if((int)mmx_init__()==0)
   printf("MMX is not supported\n");
   else
   printf("MMX is supported\n");
   return (0);
}

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

Re: [SLUG] Re: pentium M series

[Marek W]

AFAIK, there have been mixed results which depend on which version of gcc 
you're running. While reading on the topic a few months back, the general 
consensus seemed to be that in general i686 (which is what I'm compiling 
with) actually resulted in slightly slower performance in some areas but this 
WAS expected to improve as gcc evolved. 
I think it also yields somewhat longer compile times, again this is expected 
to only improve. 

In any case, I don't think there is noticeable difference in choosing either 
for most desktop environments.

I think of more importance is the march flag (which I've got set to 
"pentium-m") which are supposed to include power saving optimizations.

Cheers

Marek

On Monday 19 December 2005 12:34, Visser, Martin wrote:
> All,
>
> I just "googled" for "benchmark performance linux kernel i386 versus
> i686" and found nothing of any import. I am just wondering if anyone has
> bothered doing this. It would be nice to know what the tradeoff is
> between performance and convenience of not needing to know the CPU
> architecture. Using multi-CD distros I would also choose the closest
> matching kernel, but for my Ubuntu installs I haven't bothered.
>
> Martin

-- 
-
Marek W

--
2b | !2b
Send instant messages to your online friends http://au.messenger.yahoo.com 
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Hal Ashburner]

On Mon, 2005-12-19 at 23:40 +1100, Crossfire wrote:
> The 'correct' method to test for MMX (and later extensions) is to
> check the output of the CPUID instruction.  (Introduced in the late
> 486 families - guaranteed to be available on all Pentium class or
> newer systems however.)  It is the CPUID instruction that the linux
> kernel uses to generate most of the information in /proc/cpuinfo on
> i386 systems.

cpuid is awesome!
http://www.livejournal.com/users/kernelslacker/31732.html

At least one of the comments is so totally worth reading that you should
go ahead and funk on down there.

/me waves at Ian

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Crossfire]

O Plameras was once rumoured to have said:
> Architecture wise, some changes from i386 to i586:

> 1. Native floating  point in i586 (present in i486 but disabled, option 
> to install co-processor in i386)

Actually, the FPU in the i486 is enabled on the 486DX series, but not
on the 486SX series.  This differs from the 386 SX/DX where the 386SX
had a half-width external databus vs the full 32-bit wide databus on
the 386DX, but neither 386SX nor 386DX had an inbuilt FPU.

The Pentium saw major improvements to overall FPU performance.  When
it wasn't returning incorrect values that is.

Of course, this is all pretty moot since you'd have to be pretty crazy
to still be using a 486 (or older) class system.

However, it is important to note that there are a few 'embedded'/low
performance CPUs around that don't support the Time Stamp Counter - a
feature which Pentium optimised kernels generally require.

> 4. MMX instructions for multimedia.

MMX was only introduced in the later Pentium MMX and Pentium II CPUs.
After the introduction of MMX, the Pentium Pro (i686) was still
available, and did not support MMX.

The 'correct' method to test for MMX (and later extensions) is to
check the output of the CPUID instruction.  (Introduced in the late
486 families - guaranteed to be available on all Pentium class or
newer systems however.)  It is the CPUID instruction that the linux
kernel uses to generate most of the information in /proc/cpuinfo on
i386 systems.

C.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Crossfire]

Jan Schmidt was once rumoured to have said:
> On Mon, 2005-12-19 at 13:54 +1100, Jeff Waugh wrote:
> > 
> > 
> > > Architecture wise, some changes from i386 to i586:
> > 
> > But crucially, few of these things are interesting at the kernel
> > level. Apps can take advantage of CPU features like these
> > regardless of the architecture the kernel was built for.
> > 
> 
> The only one that really needs kernel help is MMX/SSE stuff, but that
> works regardless of the architecture the kernel is built for, provided
> it's a recent enough kernel. 

Actually, only the SSE instruction sets require kernel support - MMX
and 3dnow overload the FP registers and hence don't usually require
any additional support.

SSE, OTOH, uses a new set of registers for operations which the kernel
needs to be aware of to handle context save/restore for.

C.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Jan Schmidt]

On Mon, 2005-12-19 at 13:54 +1100, Jeff Waugh wrote:
> 
> 
> > Architecture wise, some changes from i386 to i586:
> 
> But crucially, few of these things are interesting at the kernel level. Apps
> can take advantage of CPU features like these regardless of the architecture
> the kernel was built for.
> 

The only one that really needs kernel help is MMX/SSE stuff, but that
works regardless of the architecture the kernel is built for, provided
it's a recent enough kernel. 

As long as the kernel knows about MMX/SSE, it should do the right things
with the registers even if built for '386' - it's only old kernels that
don't know about MMX/SSE at all that will break. AIUI, apps that want to
use those instructions should technically be checking /proc/cpuinfo for
the appropriate flags in order to guarantee that the kernel won't make
their data disappear, but in general it's safe anyway because everyone
is running new kernels that support all the MMX/SSE features of the
cpus.

J.

-- 
Jan Schmidt [EMAIL PROTECTED]

It all works, but it limits Linux processes to a mere 512GB of virtual
address space. Such limits are irksome to the kernel developers when the
hardware can do more, and, besides, somebody is likely to release a web
browser or office suite which runs into that limit in the near future.
- http://lwn.net/Articles/106177/


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[Ian Wienand]

On Mon, Dec 19, 2005 at 12:34:33PM +1100, Visser, Martin wrote:
> I just "googled" for "benchmark performance linux kernel i386 versus
> i686" and found nothing of any import. I am just wondering if anyone has
> bothered doing this. It would be nice to know what the tradeoff is
> between performance and convenience of not needing to know the CPU
> architecture. 

We certainly have an idea that the primitives that the operating
system use can have vastly different implications on different x86
models; costs of things like locks and memory barriers flushing
pipelines vary wildly.  General approaches like RCU in the kernel have
addressed those types of issues (in a general sense -- we know locks
are expensive so avoid them).  We have some students currently working
on a very interesting paper measuring costs of things like atomic
increments, locks and TLB fills on different architectures.  Stay
tuned for that.  But (AFAIK) the 386 kernel doesn't take much account
of these differences across sub-architectures.

Mostly I think the sub-architecture is passed via different flags to
gcc, which can try to optimise the code.  Talking with people from SGI
who look into that sort of thing, the benefits of even a much better
compiler fall into noise compared to things like lock contention.

For your general desktop user, I doubt they're really waiting much for
the kernel no matter what version they run.  If you want to know why I
say that, I have a fairly concise example :

[EMAIL PROTECTED]:~$ ldd /usr/bin/gnome-calculator
linux-gate.so.1 =>  (0xa000)
libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0x20064000)
libgnome-keyring.so.0 => /usr/lib/libgnome-keyring.so.0 
(0x20214000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x2023c000)
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0x20294000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x2037c000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x203a)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x203e8000)
libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 
(0x2059)
libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0x205fc000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x20644000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x20664000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x206c)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x206fc000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x20d14000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x20e28000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 
(0x20e7)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 
(0x20eb)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x20ed)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 
(0x20ef8000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x20f6)
libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0x20fe)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x210bc000)
libgnutls.so.11 => /usr/lib/libgnutls.so.11 (0x21364000)
libtasn1.so.2 => /usr/lib/libtasn1.so.2 (0x2145)
libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x21484000)
libnsl.so.1 => /lib/tls/libnsl.so.1 (0x2152c000)
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x21568000)
libz.so.1 => /usr/lib/libz.so.1 (0x2157c000)
libresolv.so.2 => /lib/tls/libresolv.so.2 (0x215b4000)
librt.so.1 => /lib/tls/librt.so.1 (0x215ec000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x2160c000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 
(0x216e)
libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0 
(0x2171c000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x21734000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x217b4000)
libpopt.so.0 => /lib/libpopt.so.0 (0x21874000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x21894000)
libm.so.6.1 => /lib/tls/libm.so.6.1 (0x21928000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x219fc000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x21a14000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x21a2c000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x21a44000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x21a7c000)
libc.so.6.1 => /lib/tls/libc.so.6.1 (0x21b8c000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x21e18000)
libXi.so.6 => /usr/X11R6/li

Re: [SLUG] Re: pentium M series

[O Plameras]

O Plameras wrote:


Visser, Martin wrote:


All,

I just "googled" for "benchmark performance linux kernel i386 versus
i686" and found nothing of any import. I am just wondering if anyone has
bothered doing this. It would be nice to know what the tradeoff is
between performance and convenience of not needing to know the CPU
architecture. Using multi-CD distros I would also choose the closest
matching kernel, but for my Ubuntu installs I haven't bothered.

Martin

 



Hi Martin,

This post that follows claims there's no demonstrated evidence to show
significant real performance advantage:
https://www.redhat.com/archives/fedora-devel-list/2005-January/msg00759.html 



Architecture wise, some changes from i386 to i586:
1. Native floating  point in i586 (present in i486 but disabled, 
option to install co-processor in i386)
2. Superscalar arch in i586 that allows pipelining (so allows more 
than one instruction per clock cycle)
3. 64-bit data path instead of 32-bit (so this doubles amount of data 
fetch from memory per clock cycle)
This does not mean i586 can execute 64-bit applications; registers are 
still 32-bit.

4. MMX instructions for multimedia.



I missed to include these comments.

I just want to add these implications to  Linux users like ourselves as 
far as the above are concerned.
1. If you have x86 - i686, it is clearly advantageous to install kernel 
and applications compiled 
or optimised for i686.
2. If you have x86 - i386, then install i386 kernel because clearly, 
i686 kernel will crash when

installed.

Suppliers of Linux distributions provides CD that install i386 as 
default for obvious reason, like

they want to maximise platform compatibility.

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

Re: [SLUG] Re: pentium M series

[Jeff Waugh]

> Architecture wise, some changes from i386 to i586:

But crucially, few of these things are interesting at the kernel level. Apps
can take advantage of CPU features like these regardless of the architecture
the kernel was built for.

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
"So: Stop selling software. Give it away. Work out some other way to
   make money, because pretending it's not replicable is not it. Profit."
   - Martin Pool
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: pentium M series

[O Plameras]

Visser, Martin wrote:


All,

I just "googled" for "benchmark performance linux kernel i386 versus
i686" and found nothing of any import. I am just wondering if anyone has
bothered doing this. It would be nice to know what the tradeoff is
between performance and convenience of not needing to know the CPU
architecture. Using multi-CD distros I would also choose the closest
matching kernel, but for my Ubuntu installs I haven't bothered.

Martin

 



Hi Martin,

This post that follows claims there's no demonstrated evidence to show
significant real performance advantage:
https://www.redhat.com/archives/fedora-devel-list/2005-January/msg00759.html

Architecture wise, some changes from i386 to i586:
1. Native floating  point in i586 (present in i486 but disabled, option 
to install co-processor in i386)
2. Superscalar arch in i586 that allows pipelining (so allows more than 
one instruction per clock cycle)
3. 64-bit data path instead of 32-bit (so this doubles amount of data 
fetch from memory per clock cycle)
This does not mean i586 can execute 64-bit applications; registers are 
still 32-bit.

4. MMX instructions for multimedia.

Hope this helps.

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

Combined UP/SMP [Was: [SLUG] Re: pentium M series]

[Jeff Waugh]

> You can have a *lot* of variations in your kernel config, it seems...

Interesting side point here: For 6.04, we'll be shipping a combined UP/SMP
kernel, so you don't have to worry about separate kernels for multi-cpu
machines. Rock!

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand   http://linux.conf.au/
 
   For a list of reasons why technology has failed to improve our lives,
  please press 3.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

RE: [SLUG] Re: pentium M series

[Visser, Martin]

All,

I just "googled" for "benchmark performance linux kernel i386 versus
i686" and found nothing of any import. I am just wondering if anyone has
bothered doing this. It would be nice to know what the tradeoff is
between performance and convenience of not needing to know the CPU
architecture. Using multi-CD distros I would also choose the closest
matching kernel, but for my Ubuntu installs I haven't bothered.

Martin


  

Martin Visser, CISSP
Network and Security Consultant 
Consulting & Integration
Technology Solutions Group - HP Services

410 Concord Road
Rhodes NSW  2138
Australia 

Mobile: +61-411-254-513
Fax: +61-2-9022-1800 
E-mail: martin.visserAThp.com

This email (including any attachments) is intended only for the use of
the individual or entity named above and may contain information that is
confidential, proprietary or privileged. If you are not the intended
recipient, please notify HP immediately by return email and then delete
the email, destroy any printed copy and do not disclose or use the
information in it.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Palmer
Sent: Monday, 19 December 2005 11:57 AM
To: slug@slug.org.au
Subject: [SLUG] Re: pentium M series

On Mon, Dec 19, 2005 at 10:14:15AM +1100, ashley maher wrote:
> On Sat, 2005-12-17 at 12:54 +1100, Jeff Waugh wrote:
> > 
> > 
> > > TO my surprise Ubuntu chose to install the 386 series kernel.
> > 
> > Can't fit a lot of kernels on the CD, as well as a complete desktop.

> > :-)
> 
> is this an example of gnome bloat???

More kernel bloat.  Debian woody had most of the 4th CD taken up with
various kernels.  You can have a *lot* of variations in your kernel
config, it seems...

- Matt
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] Re: pentium M series

[Matthew Palmer]

On Mon, Dec 19, 2005 at 10:14:15AM +1100, ashley maher wrote:
> On Sat, 2005-12-17 at 12:54 +1100, Jeff Waugh wrote:
> > 
> > 
> > > TO my surprise Ubuntu chose to install the 386 series kernel.
> > 
> > Can't fit a lot of kernels on the CD, as well as a complete desktop. :-)
> 
> is this an example of gnome bloat???

More kernel bloat.  Debian woody had most of the 4th CD taken up with
various kernels.  You can have a *lot* of variations in your kernel config,
it seems...

- Matt
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html