htop shows individual threads as separate processes by default, similarly to how ps -AL would. If you press capital H it will switch to only showing the main processes (pressing it again switches back). Each thread's summary information actually reflects the whole process, so they don't have separate memory counts etc. The threads will show R when active and S when not active, although because htop only refreshes every few seconds you can't actually monitor their activity easily that way, as thread switches happen much faster than that.
Performance of different threading models is complex, and beyond superuser.com - you need to detail particular issues if they arise rather than trying to guess :)
See http://groups.google.com/group/alt.os.linux.mandriva/browse_thread/thread/59c9f42e99b53663/2e6ddc78b2b85cf2?lnk=raot for more discussion of the same topic
Note that H is for user threads; for kernel threads a similar toggle key K exists, and both options are accessible under the settings menu - F2 then Display Options
Quickie, incomplete explanation:
In a thread switch, there's a lot less context you need to save/load. Specifically, memory is shared. The kernel doesn't have to do any page outs of dirty pages, and VM tricks to pull in all the memory for a new process (though some specific pages may need to be pulled in). There are other process specific data structures in the kernel (say, the open file descriptor table) that don't need to be swapped out.
As a side effect, you're also much more likely to be able to use what's in the processor's caches at that point. a new process probably needs to start a cold cache.
Yes, there are tools to share memory (IPC shared memory, pipes) between processes, but none are as clean/easy as the common memory in a process. You can't grow a shared memory block like you can with realloc() and such. Anything besides shared memory means you need multiple copies of data structures, one in each process, with tricks to copy changes as needed.
Specifically, apache has multiple models for different OSes. The original model was pre-fork, giving process isolation in exchange for some heavyweight process switching. This worked fine with the UNIXes that were common at the time of it's first writing, where some didn't have threads at all. Windows was so bad with multi-process that apache had to do threading - processes on Windows (at least at the time of apache 1.2/2.0) were too heavyweight. Linux has very light processes, where switching is close to thread switching time, so it stayed pre-Fork usually. Solaris has a complex thread "LWP" model, and does best in a hybrid thread/fork model.
Best Answer
Short answers:
Init is just the first process; it does not manage any proceses or threads. It does create some, using the kernel syscalls fork() and exec.
I think you have a muddy idea of what a process is. it doesn't just mean a bit of executing code. Yeah, the kernel executes before init (and the boot loader before that even). But a 'process' has a specific definition of:
So, once the kernel initializes, it runs init, which then spawns whatever other processes its configuration says to.
As far as #2 goes, all the kernel stuff is, well, in the kernel. Think of the kernel as a large area of code. Again, not a process, but a large code blob. Parts of the kernel deal with memory management, parts of it with scheduling portions of itself (like drivers, etc.), and parts of it with scheduling processes.