From: Sasha Levin <sasha.levin@oracle.com>
To: Hugh Dickins <hughd@google.com>
Cc: Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: mm: shm: hang in shmem_fallocate
Date: Tue, 17 Jun 2014 16:32:39 -0400 [thread overview]
Message-ID: <53A0A5E7.60908@oracle.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1406151921070.2850@eggly.anvils>
On 06/15/2014 10:29 PM, Hugh Dickins wrote:
> On Thu, 12 Jun 2014, Sasha Levin wrote:
>> > On 02/09/2014 08:41 PM, Sasha Levin wrote:
>>> > > On 02/08/2014 10:25 PM, Hugh Dickins wrote:
>>>> > >> Would trinity be likely to have a thread or process repeatedly faulting
>>>> > >> in pages from the hole while it is being punched?
>>> > >
>>> > > I can see how trinity would do that, but just to be certain - Cc davej.
>>> > >
>>> > > On 02/08/2014 10:25 PM, Hugh Dickins wrote:
>>>> > >> Does this happen with other holepunch filesystems? If it does not,
>>>> > >> I'd suppose it's because the tmpfs fault-in-newly-created-page path
>>>> > >> is lighter than a consistent disk-based filesystem's has to be.
>>>> > >> But we don't want to make the tmpfs path heavier to match them.
>>> > >
>>> > > No, this is strictly limited to tmpfs, and AFAIK trinity tests hole
>>> > > punching in other filesystems and I make sure to get a bunch of those
>>> > > mounted before starting testing.
>> >
>> > Just pinging this one again. I still see hangs in -next where the hang
>> > location looks same as before:
>> >
> Please give this patch a try. It fixes what I can reproduce, but given
> your unexplained page_mapped() BUG in this area, we know there's more
> yet to be understood, so perhaps this patch won't do enough for you.
>
>
> [PATCH] shmem: fix faulting into a hole while it's punched
>
> Trinity finds that mmap access to a hole while it's punched from shmem
> can prevent the madvise(MADV_REMOVE) or fallocate(FALLOC_FL_PUNCH_HOLE)
> from completing, until the reader chooses to stop; with the puncher's
> hold on i_mutex locking out all other writers until it can complete.
>
> It appears that the tmpfs fault path is too light in comparison with
> its hole-punching path, lacking an i_data_sem to obstruct it; but we
> don't want to slow down the common case.
>
> Extend shmem_fallocate()'s existing range notification mechanism, so
> shmem_fault() can refrain from faulting pages into the hole while it's
> punched, waiting instead on i_mutex (when safe to sleep; or repeatedly
> faulting when not).
>
> Signed-off-by: Hugh Dickins <hughd@google.com>
No shmem_fallocate issues observed in the past day, works for me. Thanks Hugh!
Thanks,
Sasha
next prev parent reply other threads:[~2014-06-17 20:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52AE7B10.2080201@oracle.com>
[not found] ` <52F6898A.50101@oracle.com>
2014-02-09 3:25 ` mm: shm: hang in shmem_fallocate Hugh Dickins
2014-02-10 1:41 ` Sasha Levin
2014-06-12 20:38 ` Sasha Levin
2014-06-16 2:29 ` Hugh Dickins
2014-06-17 20:32 ` Sasha Levin [this message]
2014-06-24 16:31 ` Vlastimil Babka
2014-06-25 22:36 ` Hugh Dickins
2014-06-26 9:14 ` Vlastimil Babka
2014-06-26 15:19 ` Vlastimil Babka
2014-06-27 5:36 ` Hugh Dickins
2014-07-01 11:52 ` Vlastimil Babka
2014-07-02 1:49 ` Hugh Dickins
2014-07-09 21:59 ` Johannes Weiner
2014-07-09 22:48 ` Hugh Dickins
2014-07-10 0:51 ` Hugh Dickins
2014-06-26 15:11 ` Sasha Levin
2014-06-27 5:59 ` Hugh Dickins
2014-06-27 14:50 ` Sasha Levin
2014-06-27 18:03 ` Hugh Dickins
2014-06-28 21:41 ` Sasha Levin
2014-07-01 22:37 ` mm: shmem: hang in shmem_fault (WAS: mm: shm: hang in shmem_fallocate) Sasha Levin
2014-07-02 0:17 ` Hugh Dickins
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=53A0A5E7.60908@oracle.com \
--to=sasha.levin@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=hughd@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).