RE: Poor thread performance on Linux vs. Solaris
"Perez-Gonzalez, Inaky" <[email protected]>
| Newsgroups | gmane.comp.lib.phil |
|---|---|
| Message-ID | <[email protected]> |
> From: Bill Soudan [mailto:[email protected]] > > It applies cleanly and the performance test runs to completion, but > unfortunately, it doesn't appear to make much of a difference wrt to > system time. I'm going to spend some time with oprofile again now that I > have your patch applied, and see if I receive different results. It'd be interesting to verify if there is still a lot of contention in the locking. A question about your app: are there many different locks used at the same time or the number is actually low? No matter how we do it, there is still a bunch of lock acquisition in the futex code that would serialize access [specially if they are locks within the same thread, like current->mm->page_table_lock]. And then we also have vcache_lock--this one is also serializing everything, as it is taken unconditionally whenever we call lock_futex_mm(). Probably if we took vcache_lock() just before doing any actual vcache operation, we'd at least improve the preemptability on that. We still need to deal with current->mm->page_table_lock. I am kind of more green on that one, but here is a question: wouldn't it be possible to drop it once we have pinned the page? This is the one that is going to hurt when interlocking between threads of the same process. Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)