From: Andy Lutomirski <luto@amacapital.net>
To: Mel Gorman <mgorman@suse.de>, Davidlohr Bueso <dave@stgolabs.net>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [Lsf-pc] [LSF/MM ATTEND] mmap_sem and mm performance testing
Date: Fri, 06 Feb 2015 18:17:05 -0800 [thread overview]
Message-ID: <54D575A1.60706@amacapital.net> (raw)
In-Reply-To: <20150102133506.GB2395@suse.de>
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>
prev parent reply other threads:[~2015-02-07 2:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 23:51 [LSF/MM ATTEND] mmap_sem and mm performance testing Davidlohr Bueso
2015-01-02 13:35 ` [Lsf-pc] " Mel Gorman
2015-02-07 2:17 ` Andy Lutomirski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D575A1.60706@amacapital.net \
--to=luto@amacapital.net \
--cc=dave@stgolabs.net \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mgorman@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.