[LSF/MM ATTEND] mmap_sem and mm performance testing

[LSF/MM ATTEND] mmap_sem and mm performance testing

[Davidlohr Bueso]

Hello,

I would like to attend LSF/MM 2015. While I am very much interested in
general mm performance topics, I would particularly like to discuss:

(1) Where we are at with the mmap_sem issues and progress. This topic
constantly comes up each year [1,2,3] without much changing. While the
issues are very clear (both long hold times, specially in fs paths and
coarse lock granularity) it would be good to detail exactly *where*
these problems are and what are some of the show stoppers. In addition,
present overall progress and benchmark numbers on fine graining via
range locking (I am currently working on this as a follow on to recent
i_mmap locking patches) and experimental work,
such as speculative page fault patches[4]. If nothing else, this session
can/should produce a list of tangible todo items.

(2) Expanding our mm performance testing. I am working on incorporating
multiple VM-intensive benchmarks taken from system research papers into
mmtests. Academics tend to choose their benchmarking material carefully
and there's no reason we cannot learn from that. The downside is that
their tools are painfully complex to use, and thus not very popular in
the kernel community. Two examples are popular suites such as mosbench
and PARSEC. The idea would be to present easy to use, higher level
benchmarks to expose in-memory scalability issues that be useful to
kernel hackers. Additionally, possibly discuss other tools folks use
that can be beneficial to our internal automation.

[1] http://lwn.net/Articles/490501/
[2] http://lwn.net/Articles/548098/
[3] http://lwn.net/Articles/591978/
[4] http://lwn.net/Articles/617344/

Thanks,
Davidlohr

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM ATTEND] mmap_sem and mm performance testing

[Mel Gorman]

On Mon, Dec 22, 2014 at 03:51:24PM -0800, Davidlohr Bueso wrote:
> Hello,
> 
> I would like to attend LSF/MM 2015. While I am very much interested in
> general mm performance topics, I would particularly like to discuss:
> 
> (1) Where we are at with the mmap_sem issues and progress. This topic
> constantly comes up each year [1,2,3] without much changing. While the
> issues are very clear (both long hold times, specially in fs paths and
> coarse lock granularity) it would be good to detail exactly *where*
> these problems are and what are some of the show stoppers. In addition,
> present overall progress and benchmark numbers on fine graining via
> range locking (I am currently working on this as a follow on to recent
> i_mmap locking patches) and experimental work,
> such as speculative page fault patches[4]. If nothing else, this session
> can/should produce a list of tangible todo items.
> 

There have been changes on mmap_sem hold times -- mmap_sem dropped by
khugepaged during allocation being a very obvious one but there are
others. The scope of what mmap_sem protects is similar but the stalling
behaviour has changed since this was last discussed. It's worth
revisiting where things stand and at the very least verify what cases
are currently causing problems.

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM ATTEND] mmap_sem and mm performance testing

[Andy Lutomirski]

On 01/02/2015 05:35 AM, Mel Gorman wrote:
> On Mon, Dec 22, 2014 at 03:51:24PM -0800, Davidlohr Bueso wrote:
>> Hello,
>>
>> I would like to attend LSF/MM 2015. While I am very much interested in
>> general mm performance topics, I would particularly like to discuss:
>>
>> (1) Where we are at with the mmap_sem issues and progress. This topic
>> constantly comes up each year [1,2,3] without much changing. While the
>> issues are very clear (both long hold times, specially in fs paths and
>> coarse lock granularity) it would be good to detail exactly *where*
>> these problems are and what are some of the show stoppers. In addition,
>> present overall progress and benchmark numbers on fine graining via
>> range locking (I am currently working on this as a follow on to recent
>> i_mmap locking patches) and experimental work,
>> such as speculative page fault patches[4]. If nothing else, this session
>> can/should produce a list of tangible todo items.
>>
>
> There have been changes on mmap_sem hold times -- mmap_sem dropped by
> khugepaged during allocation being a very obvious one but there are
> others. The scope of what mmap_sem protects is similar but the stalling
> behaviour has changed since this was last discussed. It's worth
> revisiting where things stand and at the very least verify what cases
> are currently causing problems.
>

I think that, for my workload, the main issue is that one cpu can take 
mmap_sem and get preempted, and, since we don't have priority 
inheritance, other threads in the process get stalled.

As a terrible stopgap, some kind of priority boosting, or maybe optional 
preemption disabling for some parts of the mmap/munmap code could help. 
  The speculative page fault stuff could also help.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>