I know; the point was that, based on the trap implementation, a
NULL system call wouldn't necessarily be a very useful thing.
> With respect to the tired old claims that lmbench isn't predictive of real
> world performance, I wish people would reread either the benchmark or
> the paper, or both, and then think a little before flaming. Or better
> yet, produce something better. Flaming is easy but it is basically
> masturbation without the orgasm so why bother?
With respect, I'm not flaming LMBench. I'm flaming someone who held
up LMBench results, out of context, as being somehow supportive of the
point he was trying to make. I really didn't ask for my FreeBSD-current
posting about the inefficacy of kernel threading to be partially quoted
to linux-kernel@vger.rutgers.edu, which is how I got dragged in here...
> The benchmark measures things which have been known to be performance
> problems in the past. That will not predict how /well/ future
> applications will perform. It will not predict how /well/ any
> applications will perform.
You are repeating my admonition to him. We are in violent
agreement.
> What lmbench will do, and the reason that it is popular, is tell you how
> your OS vs. somebody else's OS does on a bunch of interesting things.
Right. Exactly right. It's for people who are into that whole
motorhead mentality, where they talk about turning the clutch rotor,
putting in a racing cam, boring out the cylinders to make them
larger, and putting on dual Holly carbs and dual exhaust, etc.,
ad nausium.
For people who see a car as a tool to get from point A to point B,
it really doesn't matter.
I probably erred when I brought up context switch overhead as another
reason you would not want to do what the poster wanted to do. Mea
culpa.
> All that said, new applications can arise which have critical performance
> paths that are not measured by lmbench. To the extent that it is
> possible, I'm interested in measuring that stuff so if you have a specific
> thing you want measured, send me mail and I'll try and whip something up.
> Please note that I won't include benchmarks that are portable across Unix
> systems - no Linux specific stuff, no Solaris, no SGI, just generic stuff.
I think you mean "aren't". 8-).
The thing that would be tested here is POSIX threading performance,
which is such an ephemeral thing that I don't think you can really
quantize it to the point where you could draw conclusions about
kernel vs. user space threading in the context of SMP scalability.
I think this would fail both the portability and the quantifiability
tests necessary for a good "interesting thing". It's rather out there.
Perhaps you could test total aggregate runtime for multiple processes
with multiple threads, but I doubt this would be very interesting,
since it's pretty obvious what the results would be simply from
studying the SMP scheduler, whether there is CPU affinity, whether
there is task group affinity, whether there is CPU thread group
anti-affinity for balancing threads across CPU, etc., etc.. I'd
expect a threaded program using user space threading and not
explicitly yielding to other threads in the group to serially complete
each thread, but to have a better agregate completion time because
of the lack of process context switch overhead resulting from the
kernel thread implementation of blocking system calls. Pointing at
the obvious is rarely useful. 8-).
Terry Lambert
terry@lambert.org
--- Any opinions in this posting are my own and not those of my present or previous employers.--- "Larry McVoy has finally completely lost it, claims bad lmbench numbers lead to bad stereo performance" -- Larry McVoy- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html