[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Poor thread performance on Linux vs. Solaris



> From: Bill Soudan [mailto:bsoudan brass com]
> 
> 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)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]