Good! :-) How can I help? I have my two cpu HP XU 6/200 coming to
me this week. I've done pre-emptive thread development before, and
know how to program thread based stuff.
Join smpdev@roxanne.nuclecu.unam.mx, it is majordomo based just like
the lists on vger.
> Memory may be cheap, however on chip cache is not. This is one
> of the biggest arguments against persistant resizable storage,
> and why real systems continue to be monolithic and written in
> C/Assembler.
Bzzzt. You've missed my point.
Bzzt, you've missed my point, dynamic expandable heaps have a TLB miss
overhead not to be ignored. Resizing implies (almost always) a
reamapping of some sort, when you start playing games like this you
must virtually map the heap and thus cannot take advantage of the
large PTE sizes unless you feel that you can guarentee getting 1MB or
larger contiguous page heaps when you resize the pool.
A major ISP, relying on Linux for a 500,000 hit a day web server
would take resizable any day of the week.
Linux will be capable of 8 million or more when I get done. In any
event, you've also side stepped the issue of the extra checks and
resource tracking you must do to implement a truely resizable memory
scheme, and also the fact that a garbage collector has to run. I
don't want a garbage collector to run, thats more cycles even if it
almost always finds no work to do. Most of the papers on SMP garbage
collection schemes use extremely complex methods to do their work, if
it isn't simple it isn't something thats going to get you to the best
performance easily. At least this is what I have learned.
The problems you mention can be solved in other ways. In reality, the
large site people who I have worked with, who need the best
performance from their boxes under high load have no problem
reconfiguring a kernel.
One more variable that has to be loaded in the critical code path, one
more comparison in that path, one more cycle in that path, is too much.
Solve it some other way, believe it or not the solution that does not
require completely generic resizable buffer pools and garbage
collection will most likely be implementable in a manner which is
faster than what we have now.
I will admit right now I don't know what stays in L1 cache. I
personally doubt that a kernel structure would stay there for very
long, even on roomy 32KB separate I/D caches.
CPU designers usually provide bcopy in hardware which not only
bypasses the L1 cache, but doesn't even allocate in the L2/L3 cache if
the data isn't there already. L1 cache footprint is a big deal and I
can tell when I'm benchmarking a critical code path whether the main
data structure is hot in the L1 cache nearly all of the time (TCP hash
tables for one example).
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><