From: Michel Lespinasse <walken@google.com>
To: Chinwen Chang <chinwen.chang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
Davidlohr Bueso <dbueso@suse.de>,
Alexey Dobriyan <adobriyan@gmail.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Steven Price <steven.price@arm.com>,
Song Liu <songliubraving@fb.com>,
Jimmy Assarsson <jimmyassarsson@gmail.com>,
Huang Ying <ying.huang@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-fsdevel@vger.kernel.org, wsd_upstream@mediatek.com
Subject: Re: [PATCH v2 2/2] mm: proc: smaps_rollup: do not stall write attempts on mmap_lock
Date: Fri, 14 Aug 2020 01:35:37 -0700 [thread overview]
Message-ID: <CANN689FtCsC71cjAjs0GPspOhgo_HRj+diWsoU1wr98YPktgWg@mail.gmail.com> (raw)
In-Reply-To: <1597284810-17454-3-git-send-email-chinwen.chang@mediatek.com>
On Wed, Aug 12, 2020 at 7:13 PM Chinwen Chang
<chinwen.chang@mediatek.com> wrote:
> smaps_rollup will try to grab mmap_lock and go through the whole vma
> list until it finishes the iterating. When encountering large processes,
> the mmap_lock will be held for a longer time, which may block other
> write requests like mmap and munmap from progressing smoothly.
>
> There are upcoming mmap_lock optimizations like range-based locks, but
> the lock applied to smaps_rollup would be the coarse type, which doesn't
> avoid the occurrence of unpleasant contention.
>
> To solve aforementioned issue, we add a check which detects whether
> anyone wants to grab mmap_lock for write attempts.
I think your retry mechanism still doesn't handle all cases. When you
get back the mmap lock, the address where you stopped last time could
now be in the middle of a vma. I think the consistent thing to do in
that case would be to retry scanning from the address you stopped at,
even if it's not on a vma boundary anymore. You may have to change
smap_gather_stats to support that, though.
WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <walken@google.com>
To: Chinwen Chang <chinwen.chang@mediatek.com>
Cc: linux-arm-kernel@lists.infradead.org,
Song Liu <songliubraving@fb.com>,
wsd_upstream@mediatek.com, Davidlohr Bueso <dbueso@suse.de>,
LKML <linux-kernel@vger.kernel.org>,
"Matthew Wilcox \(Oracle\)" <willy@infradead.org>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-mediatek@lists.infradead.org,
Jimmy Assarsson <jimmyassarsson@gmail.com>,
Huang Ying <ying.huang@intel.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Steven Price <steven.price@arm.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v2 2/2] mm: proc: smaps_rollup: do not stall write attempts on mmap_lock
Date: Fri, 14 Aug 2020 01:35:37 -0700 [thread overview]
Message-ID: <CANN689FtCsC71cjAjs0GPspOhgo_HRj+diWsoU1wr98YPktgWg@mail.gmail.com> (raw)
In-Reply-To: <1597284810-17454-3-git-send-email-chinwen.chang@mediatek.com>
On Wed, Aug 12, 2020 at 7:13 PM Chinwen Chang
<chinwen.chang@mediatek.com> wrote:
> smaps_rollup will try to grab mmap_lock and go through the whole vma
> list until it finishes the iterating. When encountering large processes,
> the mmap_lock will be held for a longer time, which may block other
> write requests like mmap and munmap from progressing smoothly.
>
> There are upcoming mmap_lock optimizations like range-based locks, but
> the lock applied to smaps_rollup would be the coarse type, which doesn't
> avoid the occurrence of unpleasant contention.
>
> To solve aforementioned issue, we add a check which detects whether
> anyone wants to grab mmap_lock for write attempts.
I think your retry mechanism still doesn't handle all cases. When you
get back the mmap lock, the address where you stopped last time could
now be in the middle of a vma. I think the consistent thing to do in
that case would be to retry scanning from the address you stopped at,
even if it's not on a vma boundary anymore. You may have to change
smap_gather_stats to support that, though.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <walken@google.com>
To: Chinwen Chang <chinwen.chang@mediatek.com>
Cc: linux-arm-kernel@lists.infradead.org,
Song Liu <songliubraving@fb.com>,
wsd_upstream@mediatek.com, Davidlohr Bueso <dbueso@suse.de>,
LKML <linux-kernel@vger.kernel.org>,
"Matthew Wilcox \(Oracle\)" <willy@infradead.org>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-mediatek@lists.infradead.org,
Jimmy Assarsson <jimmyassarsson@gmail.com>,
Huang Ying <ying.huang@intel.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Steven Price <steven.price@arm.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v2 2/2] mm: proc: smaps_rollup: do not stall write attempts on mmap_lock
Date: Fri, 14 Aug 2020 01:35:37 -0700 [thread overview]
Message-ID: <CANN689FtCsC71cjAjs0GPspOhgo_HRj+diWsoU1wr98YPktgWg@mail.gmail.com> (raw)
In-Reply-To: <1597284810-17454-3-git-send-email-chinwen.chang@mediatek.com>
On Wed, Aug 12, 2020 at 7:13 PM Chinwen Chang
<chinwen.chang@mediatek.com> wrote:
> smaps_rollup will try to grab mmap_lock and go through the whole vma
> list until it finishes the iterating. When encountering large processes,
> the mmap_lock will be held for a longer time, which may block other
> write requests like mmap and munmap from progressing smoothly.
>
> There are upcoming mmap_lock optimizations like range-based locks, but
> the lock applied to smaps_rollup would be the coarse type, which doesn't
> avoid the occurrence of unpleasant contention.
>
> To solve aforementioned issue, we add a check which detects whether
> anyone wants to grab mmap_lock for write attempts.
I think your retry mechanism still doesn't handle all cases. When you
get back the mmap lock, the address where you stopped last time could
now be in the middle of a vma. I think the consistent thing to do in
that case would be to retry scanning from the address you stopped at,
even if it's not on a vma boundary anymore. You may have to change
smap_gather_stats to support that, though.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-08-14 8:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 2:13 [PATCH v2 0/2] Try to release mmap_lock temporarily in smaps_rollup Chinwen Chang
2020-08-13 2:13 ` Chinwen Chang
2020-08-13 2:13 ` Chinwen Chang
2020-08-13 2:13 ` [PATCH v2 1/2] mmap locking API: add mmap_lock_is_contended() Chinwen Chang
2020-08-13 2:13 ` Chinwen Chang
2020-08-13 2:13 ` Chinwen Chang
2020-08-13 8:21 ` Steven Price
2020-08-13 8:21 ` Steven Price
2020-08-13 8:21 ` Steven Price
2020-08-14 8:30 ` Michel Lespinasse
2020-08-14 8:30 ` Michel Lespinasse
2020-08-14 8:30 ` Michel Lespinasse
2020-08-13 2:13 ` [PATCH v2 2/2] mm: proc: smaps_rollup: do not stall write attempts on mmap_lock Chinwen Chang
2020-08-13 2:13 ` Chinwen Chang
2020-08-13 2:13 ` Chinwen Chang
2020-08-13 8:21 ` Steven Price
2020-08-13 8:21 ` Steven Price
2020-08-13 8:21 ` Steven Price
2020-08-14 8:35 ` Michel Lespinasse [this message]
2020-08-14 8:35 ` Michel Lespinasse
2020-08-14 8:35 ` Michel Lespinasse
2020-08-14 9:08 ` Chinwen Chang
2020-08-14 9:08 ` Chinwen Chang
2020-08-14 9:08 ` Chinwen Chang
2020-08-13 9:53 ` [PATCH v2 0/2] Try to release mmap_lock temporarily in smaps_rollup Michel Lespinasse
2020-08-13 9:53 ` Michel Lespinasse
2020-08-13 9:53 ` Michel Lespinasse
2020-08-13 16:11 ` Chinwen Chang
2020-08-13 16:11 ` Chinwen Chang
2020-08-13 16:11 ` Chinwen Chang
2020-08-14 8:29 ` Michel Lespinasse
2020-08-14 8:29 ` Michel Lespinasse
2020-08-14 8:29 ` Michel Lespinasse
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=CANN689FtCsC71cjAjs0GPspOhgo_HRj+diWsoU1wr98YPktgWg@mail.gmail.com \
--to=walken@google.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chinwen.chang@mediatek.com \
--cc=daniel.m.jordan@oracle.com \
--cc=dbueso@suse.de \
--cc=jgg@ziepe.ca \
--cc=jimmyassarsson@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=songliubraving@fb.com \
--cc=steven.price@arm.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=wsd_upstream@mediatek.com \
--cc=ying.huang@intel.com \
/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.