From: Jaegeuk Hanse <jaegeuk.hanse@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON
Date: Fri, 16 Nov 2012 17:34:19 +0800 [thread overview]
Message-ID: <50A6089B.7010708@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1211151126440.9273@eggly.anvils>
On 11/16/2012 03:56 AM, Hugh Dickins wrote:
> Offtopic...
>
> On Thu, 15 Nov 2012, Jaegeuk Hanse wrote:
>> Another question. Why the function shmem_fallocate which you add to kernel
>> need call shmem_getpage?
> Because shmem_getpage(_gfp) is where shmem's
> page lookup and allocation complexities are handled.
>
> I assume the question behind your question is: why does shmem actually
> allocate pages for its fallocate, instead of just reserving the space?
>
> I did play with just reserving the space, with more special entries in
> the radix_tree to note the reservations made. It should be doable for
> the vm_enough_memory and sbinfo->used_blocks reservations.
>
> What absolutely deterred me from taking that path was the mem_cgroup
> case: shmem and swap and memcg are not easy to get working right together,
> and nobody would thank me for complicating memcg just for shmem_fallocate.
>
> By allocating pages, the pre-existing memcg code just works; if we used
> reservations instead, we would have to track their memcg charges in some
> additional new way. I see no justification for that complication.
Hi Hugh
Some questions about your shmem/tmpfs: misc and fallocate patchset.
- Since shmem_setattr can truncate tmpfs files, why need add another
similar codes in function shmem_fallocate? What's the trick?
- in tmpfs: support fallocate preallocation patch changelog:
"Christoph Hellwig: What for exactly? Please explain why
preallocating on tmpfs would make any sense.
Kay Sievers: To be able to safely use mmap(), regarding SIGBUS, on
files on the /dev/shm filesystem. The glibc fallback loop for -ENOSYS
[or -EOPNOTSUPP] on fallocate is just ugly."
Could shmem/tmpfs fallocate prevent one process truncate the file
which the second process mmap() and get SIGBUS when the second process
access mmap but out of current size of file?
Regards,
Jaegeuk
> Hugh
--
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>
next prev parent reply other threads:[~2012-11-16 9:34 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-25 2:37 shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] Dave Jones
2012-10-25 4:36 ` Hugh Dickins
2012-10-25 4:50 ` Ni zhan Chen
2012-10-25 6:59 ` Hugh Dickins
2012-10-25 9:53 ` Ni zhan Chen
2012-10-25 10:21 ` Ni zhan Chen
2012-10-25 21:27 ` Hugh Dickins
2012-10-26 1:48 ` Ni zhan Chen
2012-10-25 11:14 ` Dave Jones
2012-10-25 21:28 ` Hugh Dickins
2012-10-25 20:52 ` Johannes Weiner
2012-10-25 21:48 ` Hugh Dickins
2012-10-26 2:15 ` Ni zhan Chen
2012-11-01 19:10 ` Dave Jones
2012-11-01 23:03 ` Hugh Dickins
2012-11-01 23:20 ` Dave Jones
2012-11-01 23:48 ` Hugh Dickins
2012-11-02 1:43 ` Dave Jones
2012-11-02 23:26 ` Hugh Dickins
2012-11-06 1:32 ` [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON Hugh Dickins
2012-11-06 13:54 ` Dave Jones
2012-11-06 23:48 ` Hugh Dickins
2012-11-07 22:38 ` Dave Jones
2012-11-14 1:36 ` [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON fix Hugh Dickins
2012-11-14 3:07 ` [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON Jaegeuk Hanse
2012-11-14 3:50 ` Hugh Dickins
2012-11-14 6:14 ` Dave Jones
2012-11-14 10:06 ` Hugh Dickins
2012-11-15 7:39 ` Jaegeuk Hanse
2012-11-15 19:56 ` Hugh Dickins
2012-11-16 0:40 ` Jaegeuk Hanse
2012-11-16 9:34 ` Jaegeuk Hanse [this message]
2012-11-17 4:48 ` Hugh Dickins
2012-11-18 0:57 ` Jaegeuk Hanse
2012-11-18 1:48 ` Jaegeuk Hanse
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=50A6089B.7010708@gmail.com \
--to=jaegeuk.hanse@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--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).