Negative scalability by removal of lock_kernel()?(Was:Strange performance behavior of 2.4.0-test9)
Quoted 21 lines · Linus Torvalds
No.
Please use unserialized
accept()_always_, because we can fix that.Even 2.2.x can be fixed to do the wake-one for
accept(), if required. It's not going to be any worse than the current apache config, and basically the less games apache plays, the better the kernel can try to accomodate what apache _really_ wants done. When playing games, you hide what you really want done, and suddenly kernel profiles etc end up being completely useless, because they no longer give the data we needed to fix the problem.Basically, the whole serialization crap is all about the Apache people saying the equivalent of "the OS does a bad job on something we consider to be incredibly important, so we do something else instead to hide it".
And regardless of _what_ workaround Apache does, whether it is the sucky
fcntl()thing or using SysV semaphores, it's going to hide the real issue and mean that it never gets fixed properly.
Quoted 9 lines
And in the end it will result in really really bad performance.
Instead, if apache had just done the thing it wanted to do in the first place, the wake-one
accept()semantics would have happened a hell of a lot earlier.Now it's there in 2.4.x. Please use it. PLEASE PLEASE PLEASE don't play games trying to outsmart the OS, it will just hurt Apache in the long run.
But how would you suggest people using 2.2 configure their Apache? Will flock/fcntl or semaphores perform better (albeit "uglier") than unserialized accept()'s in 2.2. I'm willing and expecting to rebuild apache when 2.4 is released. I do not, though, want to leave performance on the table today, just so I can say that my apache binary is 2.4-ready.
Do any of the apache serialization methods (flock/fcntl/semops) have any performance improvement over unserialized accept() with Apache running on a 2.2 kernel?
Dave Wagner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/