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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>