Charles Prudhomme wrote:
>
> Overhaul Linux Kernel to support Massive Multi-Threading (or Linux dies)!
>
> As microprocessor architectures are switching from single-core to dual-core
> and multi-core architectures (couple years), the operating-systems such as
> Linux must follow. The announcements from hardware makers such as Intel,
> AMD and Sun regarding their new soon to be released (within next 2 years)
> multi-core microprocessors is very revealing.
>
> The Linux kernel must undergo a deep overhaul if it does not want to fall
> into obsolescence. Linux must be updated to support massive
> multi-threading microprocessor technology. There is no way around it.
> Microsoft will surely update Windows but the Linux community seems slow to
> react. This technology will first appear in severs where Linux has a bit of
> an edge. So Linux will soon fell the heat on this.
>
> I have included below an article from the Internet magazine The Inquirer
> that talks extensively about Sun's future multi-core design. Read it
> carefully. It's a rare to find this level of details. This should give you
> an idea about what is coming in the near future.
> http://www.theinquirer.net/Default.aspx?article=19423

Linux already supports the Intel's Hyperthreading CPUs, SMP and and NUMA
systems. What makes you think that Linux won't support massive multi-threading
when the chips become available?

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
" Baldie is such a wonderful villain
The Linux/OSS community could not possibly ask for a better villain than
our man Baldie. He is absolutely perfect for the part. Just look at his
creds: 1) Physically repulsive; 2) Morally bankrupt; 3) Megalomaniacal;
4) Possessed of a truly nasty, abusive disposition; 5) Prone to Hitlerian
ranting; 6) Stalinesque paranoia... The list just goes on and on. The man
has the gift of true despicability, no doubt about it. If it weren't for
Baldie we'd be stuck with Bilgatus' merely vacuuous and creepy persona
for an anthropomorphization of the Evil Empire -- tepid at best."
-- Matthew Alton in LinuxToday.com on Steve Balmer

On Sun, 14 Nov 2004 07:22:26 +1100, Erik de Castro Lopo wrote:

> Charles Prudhomme wrote:
>>
>> Overhaul Linux Kernel to support Massive Multi-Threading (or Linux dies)!
>>
>> As microprocessor architectures are switching from single-core to dual-core
>> and multi-core architectures (couple years), the operating-systems such as
>> Linux must follow. The announcements from hardware makers such as Intel,
>> AMD and Sun regarding their new soon to be released (within next 2 years)
>> multi-core microprocessors is very revealing.
>>
>> The Linux kernel must undergo a deep overhaul if it does not want to fall
>> into obsolescence. Linux must be updated to support massive
>> multi-threading microprocessor technology. There is no way around it.
>> Microsoft will surely update Windows but the Linux community seems slow to
>> react. This technology will first appear in severs where Linux has a bit of
>> an edge. So Linux will soon fell the heat on this.
>>
>> I have included below an article from the Internet magazine The Inquirer
>> that talks extensively about Sun's future multi-core design. Read it
>> carefully. It's a rare to find this level of details. This should give you
>> an idea about what is coming in the near future.
>> http://www.theinquirer.net/Default.aspx?article=19423
>
> Linux already supports the Intel's Hyperthreading CPUs, SMP and and NUMA
> systems. What makes you think that Linux won't support massive multi-threading
> when the chips become available?
>
> Erik

Do you have any clue what SMT is all about?

They were slow to even recognize this, RH was the first to support it in
some fashion as Intel worked with them on it, everybody else was years
behind and it is still not fully implemented.

The words of warning were to start now, not five years from now. This also
applies to software programmers and threading. Unless the framework is
setup properly then what good is it if the software does not use it
properly?

Linux is always slow to react. Largely in part because everyone is focused
on existing projects, and largest use audience. Somewhat because it was
server oriented and the high tech crap didn't matter much other than SCSI
stuff.

Linus did start a massive overhaul of the OS which is still a WIP and I am
not sure how forward compatible it is.

Unless the community somehow bands together and creates a R&T group fully
focused on HW, then it will fall way behind in the open/free area's. The
only ones that might advance are the major players that are commercialized.
Even those will be limited unless they can get Linus and group to work on
"private" projects for the commercial distro's.

WTH it will work on older hdwe and that is all most of the cheap bastards
are running anyhow until their chit breaks and they can't repair the system
any longer.

Perhaps govt funded projects like in Germany, etc. may be the only way to
keep it up to speed in a timely fashion. However, would you be willing to
trust this in the hands of any govt?

Iceman wrote:
>
> Do you have any clue what SMT is all about?

Symmetric Multi Processing yes, SMT no. Enlighten me.

> They were slow to even recognize this, RH was the first to support it in
> some fashion as Intel worked with them on it, everybody else was years
> behind and it is still not fully implemented.

If the above is about SMP, then its wrong. SMP was in the
kernel long before RH shipped it because it was in a
development kernel and RH doesn't ship development kernels.

> The words of warning were to start now, not five years from now.

People have been saying "the sky is falling" for a long time
too.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Everyone seems to assume that the current system in America is capitalism.
I beg to differ. True capitalism does not involve false advertising,
distribution cartels, or political lobbying for special advantages in the
market. How can you call Microsoft or the RIAA capitalist, when their main
business is interfering with a free market? Some of us would like to see a
*return* to capitalism in this country. - Jim Flynn on Linuxtoday.com

The world rejoiced as Erik de Castro Lopo <nospam@mega-nerd.com> wrote:
> Iceman wrote:
>>
>> Do you have any clue what SMT is all about?
>
> Symmetric Multi Processing yes, SMT no. Enlighten me.

SMT == "Simultaneous multi threading"

>> They were slow to even recognize this, RH was the first to support
>> it in some fashion as Intel worked with them on it, everybody else
>> was years behind and it is still not fully implemented.
>
> If the above is about SMP, then its wrong. SMP was in the kernel
> long before RH shipped it because it was in a development kernel and
> RH doesn't ship development kernels.
>
>> The words of warning were to start now, not five years from now.
>
> People have been saying "the sky is falling" for a long time too.

Indeed.

At the "advanced" end, SMT might lead to having as many as 16
processor cores on a die, which would mean having to do some form of
16-way multiprocessing in order to take advantage of it.

The expectation, therefore, is that applications have to spawn Plenty
O Kernel Threads in order to take advantage of having 16 CPUs.

REALITY is that researchers have been working on multiprocessing
systems for decades, and there has been no "silver bullet" to make it
easy to write general purpose multiprocessing applications. There are
programming APIs like MPI, and implementations like Beowulf; they are
only useful for a limited class of applications.

Some applications will take little or no benefit from having multiple
CPUs, but actually there are plenty of cases already where they will.

Consider:

1. If you're running X along with 5 other applications. If you have
6 CPUs, each of those processes can (and likely will) run on
separate CPUs.

2. If you have a pipeline looking like:

cat $HOME/big_file | filter1 | filter2 | filter3 > $HOME/output

That leads to having 4 processes, each of which can (and likely
will) migrate to separate CPUs.

3. I do a lot of work with PostgreSQL. It doesn't particularly
"speak threads," but rather uses a forking model where separate
connections are attached to separate processes.

On a system with many CPUs, those processes will spread out
across the CPUs, so that if I have 16 concurrent processes,
pretty much all of the CPUs on a 16-way system should get
harnessed.

What is missing in each of these cases is the notion of one
application spreading itself across many CPUs via threading. The
database spreads out without threading, but any sort of monolithic
single process application will be confined to one CPU.

For instance, Mozilla and OpenOffice.org each behave as one process,
with "one kernel thread." You can get some benefit of multiprocessing
by having X run on one CPU, Mozilla on another, and OpenOffice.org on
a third, but they can't spread themselves across another 13 CPUs.

This tells me something unsurprising, namely that huge monolithic
applications are somewhat evil. "Good" applications on Linux should
spawn helper processes, at least in this context.
--
(reverse (concatenate 'string "gro.mca" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/sap.html
Everyone has a photographic memory, some don't have film.

Christopher Browne wrote:

> The world rejoiced as Erik de Castro Lopo <nospam@mega-nerd.com> wrote:
>> Iceman wrote:
>>>
>>> Do you have any clue what SMT is all about?
>>
>> Symmetric Multi Processing yes, SMT no. Enlighten me.
>
> SMT == "Simultaneous multi threading"

I've never hear of that acronym. FYI proper SMP implementation provides for
simultaneous thread execution.

>
>>> They were slow to even recognize this, RH was the first to support
>>> it in some fashion as Intel worked with them on it, everybody else
>>> was years behind and it is still not fully implemented.
>>
>> If the above is about SMP, then its wrong. SMP was in the kernel
>> long before RH shipped it because it was in a development kernel and
>> RH doesn't ship development kernels.
>>
>>> The words of warning were to start now, not five years from now.
>>
>> People have been saying "the sky is falling" for a long time too.
>
> Indeed.
>
> At the "advanced" end, SMT might lead to having as many as 16
> processor cores on a die, which would mean having to do some form of
> 16-way multiprocessing in order to take advantage of it.
>
> The expectation, therefore, is that applications have to spawn Plenty
> O Kernel Threads in order to take advantage of having 16 CPUs.
>
> REALITY is that researchers have been working on multiprocessing
> systems for decades, and there has been no "silver bullet" to make it
> easy to write general purpose multiprocessing applications. There are
> programming APIs like MPI, and implementations like Beowulf; they are
> only useful for a limited class of applications.
>
> Some applications will take little or no benefit from having multiple
> CPUs, but actually there are plenty of cases already where they will.
>
> Consider:
>
> 1. If you're running X along with 5 other applications. If you have
> 6 CPUs, each of those processes can (and likely will) run on
> separate CPUs.

Yup
>
> 2. If you have a pipeline looking like:
>
> cat $HOME/big_file | filter1 | filter2 | filter3 > $HOME/output
>
> That leads to having 4 processes, each of which can (and likely
> will) migrate to separate CPUs.

Depending on the flow across the pipeline, perhaps, but yes, it is possible.

>
> 3. I do a lot of work with PostgreSQL. It doesn't particularly
> "speak threads," but rather uses a forking model where separate
> connections are attached to separate processes.
>
> On a system with many CPUs, those processes will spread out
> across the CPUs, so that if I have 16 concurrent processes,
> pretty much all of the CPUs on a 16-way system should get
> harnessed.

Yes, and PostgreSQL along with many other database type systems will scale
across CPU until you hit an I/O bottleneck.

>
> What is missing in each of these cases is the notion of one
> application spreading itself across many CPUs via threading. The
> database spreads out without threading, but any sort of monolithic
> single process application will be confined to one CPU.

True.
>
> For instance, Mozilla and OpenOffice.org each behave as one process,
> with "one kernel thread." You can get some benefit of multiprocessing
> by having X run on one CPU, Mozilla on another, and OpenOffice.org on
> a third, but they can't spread themselves across another 13 CPUs.

Also true.
>
> This tells me something unsurprising, namely that huge monolithic
> applications are somewhat evil. "Good" applications on Linux should
> spawn helper processes, at least in this context.


Well, it is a bit more complex than it looks. Many simple algoritms are
either incapable of being divided into threads or become an order of
magnitude more difficult.

Take the classic sort algorithm, conceptually very easy to divide across
many threads, implementation, however is very difficult to do in a generic
way. Executing processes across multiple CPUs works really well. Using
threads to service connections in a server application works.

Taking a single logical progression of instructions which will branch based
on various conditions and turing it into a multiple thread execution is
very difficult (I dare not say impossible) to do. There are threaded
applications which are designed to take advantage of SMP. The whole pthread
API is designed to facilitate this. The difference is that tasks are broken
up into multiple logical progressions were possible.

> cat $HOME/big_file | filter1 | filter2 | filter3 > $HOME/output
>
> That leads to having 4 processes, each of which can (and likely
> will) migrate to separate CPUs.

Instead use:
< $HOME/big_file filter1 | filter2 | filter3 > $HOME/output
which requires only 3 processes to accomplish the same thing.

--

On Sun, 14 Nov 2004, John Reiser wrote:

>> > cat $HOME/big_file | filter1 | filter2 | filter3 > $HOME/output
>> >
>> > That leads to having 4 processes, each of which can (and likely
>> > will) migrate to separate CPUs.
>>
>> Instead use:
>> < $HOME/big_file filter1 | filter2 | filter3 > $HOME/output
>> which requires only 3 processes to accomplish the same thing.

Put down the golf club, this is a tennis match.

OP points out that MT and MP are not identical. I am not sure how the
difference makes any difference if the threads are schedulable
independently. How well the kernel handles MT vs MP capability is not
known (to me) and appears to be the focus of this thread, not whether
the example can be trimmed from 4 stages to 3.

FWIW any of those filters might fork processes to carry parts of the
work without Mr Dumb User (me) knowing it, whether those have multiple
threads is another unknown, and both questions miss the interesting
point of the thread: Are the Linux kernels as MT-capable as they are
MP-capable?


--
Brian Brunner
911: Gov't Sponsored Dial-a-Prayer.
1911: A gun in the hand beats two on the phone.
9-11-01: Four Hijackings, and thousands of deaths,
because Gun Banners disarmed the pilots to keep us safe.
..45ACP: Cure for the Common Criminal.

This is not a .sig, it's a .glock! *jeesh*

A long time ago, in a galaxy far, far away, John Reiser <jreiser@BitWagon.com> wrote:
>> cat $HOME/big_file | filter1 | filter2 | filter3 > $HOME/output
>> That leads to having 4 processes, each of which can (and likely
>> will) migrate to separate CPUs.
>
> Instead use:
> < $HOME/big_file filter1 | filter2 | filter3 > $HOME/output
> which requires only 3 processes to accomplish the same thing.

Yeah, that's a "gratuitous use of cat." So sue me. If there's a CPU
free, then it's a fairly irrelevant overhead.

Or add an extra few filters, so that there are _more_ processes,
thereby making use of extra CPUs.
--
select 'cbbrowne' || '@' || 'ntlug.org';
http://www3.sympatico.ca/cbbrowne/advocacy.html
Rules of the Evil Overlord #115. "I will not engage an enemy
single-handedly until all my soldiers are dead. (Which is a good
point at which to retreat in any case.)"
<http://www.eviloverlord.com/>

After a long battle with technology, mlw <mlw@nospam.no>, an earthling, wrote:
> Christopher Browne wrote:
>
>> The world rejoiced as Erik de Castro Lopo <nospam@mega-nerd.com> wrote:
>>> Iceman wrote:
>>>>
>>>> Do you have any clue what SMT is all about?
>>>
>>> Symmetric Multi Processing yes, SMT no. Enlighten me.
>>
>> SMT == "Simultaneous multi threading"
>
> I've never hear of that acronym. FYI proper SMP implementation
> provides for simultaneous thread execution.

It's a new acronym that Sun and Intel are evidently using to describe
the usage of their multicore CPUs.

>> This tells me something unsurprising, namely that huge monolithic
>> applications are somewhat evil. "Good" applications on Linux should
>> spawn helper processes, at least in this context.

> Well, it is a bit more complex than it looks. Many simple algoritms
> are either incapable of being divided into threads or become an
> order of magnitude more difficult.
>
> Take the classic sort algorithm, conceptually very easy to divide
> across many threads, implementation, however is very difficult to do
> in a generic way. Executing processes across multiple CPUs works
> really well. Using threads to service connections in a server
> application works.

Well, that means that you're not going to get much value out of trying
to multithread (or multitask) a sort.

I sure wouldn't have expected sorting to be an example of an
application that would improve performance by spawning helper
processes.

> Taking a single logical progression of instructions which will
> branch based on various conditions and turing it into a multiple
> thread execution is very difficult (I dare not say impossible) to
> do. There are threaded applications which are designed to take
> advantage of SMP. The whole pthread API is designed to facilitate
> this. The difference is that tasks are broken up into multiple
> logical progressions were possible.

That's not what I'm thinking of.

What I was thinking of was more along the lines that complex apps like
Mozilla and OpenOffice.org lend themselves to having plenty of
components that it would make sense to spawn as separate processes
that could invisibly take advantage of SMP.

For instance, Mozilla has to split off threads to do such things as:
- managing concurrently loading data from many data sources
- sometimes data sources use SSL; sometimes they don't...
- caching recently-read data

In all of these cases, it would make a fair bit of sense to split
this off to one or more separate processes in much the way people
use Squid as a web proxy. At one point, someone tried adding SSL
support to Lynx via redirecting https requests to a separate SSL
proxy process so that Lynx wouldn't have to know about data
encryption at all.

- data storage (e.g. - configuration properties, XUL files, chrome,
and such)

Perhaps storage could be managed by a separate "database" process?

- displaying and managing bookmarks

perhaps simplified if there was a "database" process?

- rendering web pages

The obvious part...

- resolving addresses

Which has historically been done in a separate process...

I'm not sure what is the "perfect" architecture, but I can easily see
Mozilla splitting into half a dozen processes. That would _easily_
spread it across more CPUs in a multiprocessor context.

The same could be true for OpenOffice.org.
--
let name="cbbrowne" and tld="acm.org" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
"My experience as a member of the APB (Accounting Principles Board)
taught me many lessons. A major one was that most of us have a
natural tendency and an incredible talent for processing new facts in
such a way that our prior conclusions remain intact."
-- Charles Horngren

On Sun, 14 Nov 2004 18:26:44 +1100, Erik de Castro Lopo wrote:

> Iceman wrote:
>>
>> Do you have any clue what SMT is all about?
>
> Symmetric Multi Processing yes, SMT no. Enlighten me.
>

http://www.lienhart.de/Publications/MSE2002.pdf

Here is one of many papers on the subject. You might want to do a google
search on SMT+Linux. It is currently possible in limited from with the new
kernels. It is currently available in various Intel CPU's, least expensive
of which is the even numbered P4 CPU's.

>> They were slow to even recognize this, RH was the first to support it in
>> some fashion as Intel worked with them on it, everybody else was years
>> behind and it is still not fully implemented.
>
> If the above is about SMP, then its wrong. SMP was in the
> kernel long before RH shipped it because it was in a
> development kernel and RH doesn't ship development kernels.
>

No, it isn't SMP and if you were to read some of the papers on Intel's site
you will see what I was writing about. SMP and SMT are related in a way,
but they are not the same.

Look how many years it took for SATA to be enabled, it was much simpler to
implement, yet.....

>> The words of warning were to start now, not five years from now.
>
> People have been saying "the sky is falling" for a long time
> too.
>

True, but the OP was still correct. They are already behind the eight ball
on this. Software programmers need to be aware of it in order to make use
of it in the Linux community. It is already being used in the Win
community. May be in the linux community, I'm just not aware of it.