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)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.