> Try a more meaningful benchmark, one that actually does something in > the kernel before returning, and see how they do. Try calling kill > or socket/close a few hundred thousand times and see how they do.
Or that horribily impracticle wake-one semantics implemented under SMP for the accept() function with recent Linux kernels to prevent overscheduling. Or another really useless thing like releasing a MP lock in the TCP/IP stack the increases user space copies by a factor of 4 times in the Linux kernel. FreeBSD still using a single big kernel lock which slows down certain unimportant things like getting every so slow course grained kernel lock ? Are things breaking with all the new changes in the FreeBSD kernel ? Uh, "yes" to the two above questions ? > Wes Peters Softweyr LLC bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
