Re: 2.2.18Pre Lan Performance Rocks!

["Jeff V. Merkey" <jmerkey@timpanogas.org>]

Alan Cox wrote:
> 
> > Why not solve the problem at the source and completely redesign the
> > network stack? Get rid of the old sk_buff & co! Rip the whole network
> > layer out! Redesign it and give the user a possibility of Zero-Copy
> > networking!
> 
> For one because you don't need to do that to get zero copy networking for
> most real world cases. Tux already implements the neccessary infrastructure
> for these.

The code in the networking layer is fine, in fact, it's absolutely
great.  This is not
the problem.   The problem are all the clocks wasted reloading TLBs and
the background 
memory activitiy caused by Linux's heavy dependence in Intel's
protection hardware model.

Step 1 is to load the entire OS at ring 0 with protection completely
disabled system wide, 
put in the kernel optimizations for AGI and context switch locking, and
stub the top half of Linus's scheduler.  The global memory structures in
his kernel may or may not hurt performance, depending on how they are
accessed by multiple processors.  I will need to start profiling with a
ring 0 port first and determine frequency of access that's hardware
measured.

The next step would be to start peeling off different subsystems and
re-parallelizing them 
on the merged kernel.  There's an awful lot of areas in Linus' that are
going to be a 
problem, but I'll work through them one at a time.  When I first
parallelized NetWare, I wrote
an independent SMP kernel then loaded the entire NetWare 4.1 image as a
single process.  The next step was to start peeling off layers from
NetWare and plugging them in one by one and parallelizing them.  I am
using the same approach here.  When I was finished, I had peeled NetWare
like a banana and completely reintegrated it on a new kernel.  This
approach works because it allows you to stage each layer.

The next step will be to modify the loader to allow the existing
protection scheme to exist in true user space.  WRD's will hold off CR3
switching so long as I/O is coming in or out of the box.  I anticipate
this will take until March of next year to get right.

Jeff






packets via a WTD scheduler,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/