| |||||||||||||
Volatile ranges with fallocate()Volatile ranges with fallocate()Posted Jun 8, 2012 10:27 UTC (Fri) by juliank (subscriber, #45896)Parent article: Volatile ranges with fallocate()
I think that's not really useful in its current way. Instead, this should be part of the madvise() family, and work on anonymous memory as well.
Otherwise, making it useable for applications is basically almost impossible.
(Log in to post comments)
Volatile ranges with fallocate() Posted Jun 9, 2012 1:08 UTC (Sat) by ncm (subscriber, #165) [Link]
/tmp might or might not be tmpfs, /dev/shm is tmpfs. Mapping a shared memory region with shm_open and mmap, and then shm_unlinking it, should make it indistinguishable from anonymous memory. Right?
Volatile ranges with fallocate() Posted Jun 9, 2012 2:38 UTC (Sat) by foom (subscriber, #14868) [Link] Sure, but this API is a really convoluted and irritating way to make users go about things..Consider the two options (note: code written in comment editor, may not actually work; error handling omitted): Option 1: volatile_storage = mmap(0, 163840, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, 0, 0);API option 2, retardedly difficult for no good reason:
int fd = -1;
char *name;
while (fd == -1) {
name = tmpnam(NULL);
fd = shm_open(name, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR);
}
shm_unlink(name);
ftruncate(fd, 163840);
volatile_storage = mmap(NULL, 163840, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
Then, the usage is ridiculous too:
Sane API:
madvise(object_addr, 4096, MADV_VOLATILE);Insane API: // First implement a function "find_mapping_info_for" which does e.g. a binary // search through a list of shm_open'd regions, to find one that contains the // address in question. Then... mapping_info = find_mapping_info_for(object_addr); fallocate(mapping_info.fd, FALLOCATE_FL_MARK_VOLATILE, object_addr - mapping_info.base_addr, 4096);Why would anyone want the second API?...it basically requires users to go through an extra song-and-dance at mmap time, to keep extra file descriptors open, and to track which file descriptors belong to which memory regions, for seemingly no reason.
Volatile ranges with fallocate() Posted Jun 9, 2012 6:32 UTC (Sat) by ncm (subscriber, #165) [Link]
It seems like anonymous mmap might as well be implemented using shm under the covers. Maybe it is.
The sample code looks plausible, but you omitted code to check whether backing store for an address range has been reclaimed. Actually we don't need a new flag; MADV_MREMOVE suffices. The docs don't say what the process would find in an MREMOVEd page, were it to look, or what marking a previously MREMOVEd range MADV_NORMAL does. Mark it MADV_NORMAL to be see if everything written is still there. If that fails, check progressively smaller ranges. Or unmap the lot and forget all about it. Or mark it DONTNEED, equivalent to munmapping and re-mmapping the address range.
Volatile ranges with fallocate() Posted Jun 11, 2012 16:38 UTC (Mon) by jstultz (subscriber, #212) [Link]
So I moved from madvise to fadvise early on because the need to be able to coordinate shared volatile ranges between processes, in the fashion ashmem provides.
That said, once the backing infrastructure for fallocate() volatile regions is upstream, there isn't a reason why a simpler madvise interface wouldn't also be viable.
I'd invite you to join the discussion on lkml to further discuss this.
|
|||||||||||||