Re: DP performance

[Miguel Filipe <miguel.filipe@xxxxxxxxx>]

On 4/28/05, Danial Thom <danial_thom@xxxxxxxxx> wrote:
> 
> --- Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
> wrote:
> > :No, sorry. I thought thats what you guys were
> > :doing. How long do you think it will be before
> > :any of the 4.x derivatives are actually better
> > :than 4.x?
> > :
> > :Danial
> >
> >     Well, the main issue is that the original
> > BSD code (and the
> >     original linux code for that matter) was
> > not designed to operate
> >     in an MP environment.  Fixing it requires
> > rewriting most of the
> >     major subsystems in the kernel.
> >
> >     We are fairly close to being able to
> > parallelize the protocol
> >     stacks.  We can certainly run the interrupt
> > *threads* on any
> >     cpu, once we get the BGL turned off in the
> > threads.  Directing
> >     an actual hard interrupt to the appropriate
> > cpu is harder.
> 
> Is there any evidence that chopping up the kernel
> into threads yields a net gain with 2 processors?
> Linux is supposedly very good at MP, and linux
> with 2 processors is still outperformed by
> FreeBSD 4 with one.

Show me were, From what I've seen, linux kicks ASS in MP environments.
with threads and with processes...
Linux 2.6 scales better with load(see fefe's benchmarks) and cpus
(linux works on a 512cpu beast, made by SGI...can´t imagine FreeBSD
running on a 8< cpu machine...)
But hey. I might be biased, and i've only really used OpenBSD and
DragonFlyBSD .. but from the kernel specs of linux... it scales
beastly now...
, 

 How many processors do you
> need to make up for the inefficiencies you create
> by threading the kernel? Or do we just assume
> that more is better? Probably running 2 distinct
> kernels on a single machine would yield better
> results than a single, threaded kernel. It seems
> like a lot of work to just get to where you were
> before.


Two kernels on a single machine?
Care to explain?
I've never seen that being taken has a real possibility, but I can't
argument on why...

> 
> Danial
>