From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751562Ab2KPJeb (ORCPT ); Fri, 16 Nov 2012 04:34:31 -0500 Received: from mail-pa0-f46.google.com ([209.85.220.46]:63823 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751231Ab2KPJe3 (ORCPT ); Fri, 16 Nov 2012 04:34:29 -0500 Message-ID: <50A6089B.7010708@gmail.com> Date: Fri, 16 Nov 2012 17:34:19 +0800 From: Jaegeuk Hanse User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hugh Dickins CC: Dave Jones , Andrew Morton , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> <20121102014336.GA1727@redhat.com> <20121106135402.GA3543@redhat.com> <50A30ADD.9000209@gmail.com> <50A49C46.9040406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx202.postini.com [74.125.245.202]) by kanga.kvack.org (Postfix) with SMTP id 2049C6B006C for ; Fri, 16 Nov 2012 04:34:30 -0500 (EST) Received: by mail-pb0-f41.google.com with SMTP id xa7so1983104pbc.14 for ; Fri, 16 Nov 2012 01:34:29 -0800 (PST) Message-ID: <50A6089B.7010708@gmail.com> Date: Fri, 16 Nov 2012 17:34:19 +0800 From: Jaegeuk Hanse MIME-Version: 1.0 Subject: Re: [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> <20121102014336.GA1727@redhat.com> <20121106135402.GA3543@redhat.com> <50A30ADD.9000209@gmail.com> <50A49C46.9040406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Dave Jones , Andrew Morton , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org 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: email@kvack.org