Linux Kernel Network Subsystem Patching

[D. Hugh Redelmeier]

| From: Aruna Hewapathirane <aruna.hewapathirane-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>

| *Bit of a read but truly helped me to understand Hyperthreading vs
| Multi-threading vs Super Threading, may help others so sharing : *

I found that very confusing, and I understood the subject before
reading it.

The term "thread" in hardware is not the same as "thread" in
software.  A thread in hardware is just the execution of a process
(which might involve execution of a software thread).

A "thread" in software is just a process that shares a lot of
resources with other threads.


Software view:

Unix Process: essentially a running program.  Remember, you can have
multiple instances of the running program, assuming it is written to
not have multiple instances trip over each other.

This "trip over each other" criterion is actually very important.  Old
style Unix programs did that pretty well.  The only issue was global
resources, for example a wired-in file that might be written to.

Unfortunately, most GUI programs to have global resources that they
don't share well: config files, caches, and who knows what else.  When
you try to run multiple copies of Firefox, it discovers this and
actually only runs the one copy, with multiple windows.

Windows programs (of which I know little) seem to be like GUI
programs: they are not very good at having multiple instances NOT
stepping on each other.

Unix processes can only share a few things accidentally (files), and
they are fairly easy to get straight.

Threads are different.  Traditionally, multiple threads within the
same program share almost everything.  For example, memory and hence
most variables.  So instances very easily step on each other.  It takes a
lot of care to design a program with threads that is both efficient and
not buggy.  It's not a great paradigm and I avoid it like the plague.

Multiprogramming / multi-tasking: a property of an operating system
(OS) that allows multiple processes to run at (roughly) the same time.
All modern OSes do that, but it wasn't always so.

Hardware view:

Multiprocessor: hardware with multiple CPUs.  It takes work to make an
OS support it, but Linux got that support about 20 years ago.  Windows
has it too.  Unix and OSX have supported it for quite a while.  To
properly written user software, it is a non-issue because all that
happens is that the OS can let multiple process run and exactly the
same time, which is more or less indistinguishable from (roughly) the
same time.

An OS might do a better job if it knows that certain paths between
pairs of processors have different costs (eg. NUMA, shared caches,
...).  For example, an OS scheduler probably tries to restart a
process on the same processor on which it ran the last time in the
hope that the cache retains relevant data.

Multicore: a multiprocessor that has several CPUs on the same chip.
>From a software view, indistinguishable from Multiprocessor.

HyperThreaded (HT): Intel's trademark(?) for Simultaneous
Multi-Threaded (SMT). It has probably displaced SMT as a term.

Simultaneous Multi-Threaded: implement multi-core, but with a lot of
shared hardware resources.  These hardware resources are expensive.
By design, this sharing is invisible to software, except for
performance.  SMT can opportunistically keep the hardware usefully
employed when work on one process is "stalled" (eg. due to a memory
fetch).  How can this go wrong (apart from bogus implementation)?
One way is that things like the L1 cache are likely shared and
therefore less effective for each "processor".

Since the OS can switch a processor between processes when progress on
the first is delays (multitasking), why is SMT useful?  Because
multitasking and SMT operate on quite different time scales.  Process
switching takes many microseconds and involves storing and restoring a
lot of state (eg. registers), taking many OS instructions.  SMT
switching is all done by hardware and takes just a few machine cycles,
less than the time to access a single memory location.  But SMT
requires that the hardware have duplicate resources for holding
exactly that state.

Multitasking is good for exploiting hardware that would otherwise be
idle while waiting for I/O.  SMT is good for exploiting hardware that
would be idle while awaiting a memory fetch.

Summary: as a programmer, you don't need to care about Multicore, HT,
SMT.  Except that you need to remember that processors are not getting
faster, they are getting wider.  If you don't parallelize your
software stack, you are not getting all the CPU crunch out of your
hardware.  If CPU isn't a bottleneck, then this matters not at all.

Don't write multi-threaded programs without a great deal of
forethought.

There are ways of exploiting multiprocessing that are easy:

- lots of independent programs can be run at the same time

- lots of copies of the same program can be run (as long as it is
  polite about sharing global resources)

- you can write programs in a language which doesn't force the
  programmer to explicitly deal with threads (eg. Erlang).
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists