Re: Comments on the KSE option

On Tue, 2006-10-31 at 07:54 +1100, Peter Ross wrote:
> On Mon, 30 Oct 2006, Massimo Lusetti wrote:
> 
> > On Sat, 2006-10-28 at 20:47 +0100, Robert Watson wrote:
> > 
> > > significantly slower than multi-process ones.  Many programmers believe that 
> > > threading is necessarily faster than using multiple processors, so I think 
> > > we're fundamentally forced to deal with the way they do use them, rather than 
> > > how they should use them.
> > 
> > I'm in sync with your opinion but speaking from the point of view of a
> > programmer which use FreeBSD i would like to say that enforcing (or at
> > least try to) good understanding of issues and good programming practice
> > is a good thing(TM), so if FreeBSD as an O.S. and as a community try to
> > enforce me to have good programming attitudes i really would like to
> > follow that.
> 
> I'm not a kernel developer, and not even a 'real' developer, I am just a 
> sys admin who hopes to get the best from the OS. At the moment I am 
> responsible for a bunch of servers to run a homegrown Java application. So 
> sorry if my thoughts here sound a bit naive.
> 
> The way the JVM exposes the threads to the OS just seems as a "natural" 
> way to me, especially if you are program for more then one OS. I 
> understand it as "leave it to the OS to sort things out. It should know 
> how to use the resources".
> 
> I administrate SMP servers running a resource-hungry Java/tomcat app. The 
> JVM has several hundred threads, e.g. 100 for every DB connection in a 
> connection pool.
> 
> It is difficult to imagine that a thread, a "light-weight process" causes 
> more kernel congestion than a process. I doubt it is the programmer's 
> fault, I would think there is something wrong withg the implementation.

It really is not that hard to imagine -- just think of what needs to be
done when multiple threads of the same process executing on multiple CPU
are trying to do sbrk(2), open(2) or mmap(2) -- apart from usual
activity for the single threaded process you have to make sure that
characteristics of the process as the whole (break value, first
available file descriptor or available virtual address in the process
space) stay consistent. Then you have my all-time favorite -- signal
delivery to the threaded process. And then multithreaded process does
fork(2)...

> What means fairness in this context? (Simplification here) I don't hope 
> that the sshd gets half of the CPU if I login. I just hope that I get a 
> share to type a kill command if necessary;-)

It might be presumptious of me to speak on the subject I don't
necessarily completely understand myself, but an impression I got from
this E-mail thread is that concept of "fairness" would differ
dramatically between application programmer trying to wring every drop
of performance from the single-purpose multi-CPU box and sysadmin
supporting multi-user/multi-application environment. What seem to be
perfectly "fair" to the former is completely "unfair" to the latter.

Conversely, I think it is unfair to make me break my single-process
multi-threaded application into multiple communicating processes to
achieve performance gain (true story, not FreeBSD though ;)

-- 
Alexandre "Sunny" Kovalenko