On Sun, Oct 13, 2002 at 06:59:38PM +1000, Anton Blanchard wrote:
> My 24 way SMP disagrees with your analysis:
> http://samba.org/~anton/linux/2.5.40/dbench/
> Thats just ext2. dbench is a filesystem benchmark that is heavy on
> inode/block allocation.
> Please show us your profiles which show linux filesystems do not
> utilise SMP.
Low-level fs driver block allocation etc. does appear to be an issue in
the fs-intensive benchmarks I run. In fact, the it's the only remaining
serious lock contention issue besides the dcache_lock, and that's
solved in akpm's tree. I have assurances work is being done on block
allocation and am not too concerned about it.
The rest of the trouble I see is lock contention in the page allocator
(solved in akpm's tree), stability (%$#*!), scheduler/VM/vfs/block I/O
data structure space consumption, and raw cpu cost of various
algorithms. pmd's are particularly pernicious (dmc had something for
this), followed by buffer_heads, task_structs, names_cache (mostly an
artifact of the benchmarks, but worth fixing), and inodes.
Last, but not least, when OOM does occur, the algorithm for OOM
recovery does not degrade well in the presence of many tasks. There is
also an issue with the arrival rate to out_of_memory() being O(cpus)
and the OOM killer being based on arrival rates, but not scaling its
threshholds appropriately. The former means that the OOM killer is
triggered falsely, and the latter means the box is unresponsive for so
long in OOM kill sprees it is dead period.
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:45 EST