Linux VM use-once mechanisms don't seem to work. Simple scenario like streaming a file much greater than physical RAM size should be identified to avoid trashing the page cache with useless data. I know the VM cannot predict the future or assume anything about the user's intent. But this workload is simple and common, it should be detected and better handled. Test case: Linux 2.6.20-16-lowlatency SMP PREEMPT x86_64 (also tried on 2.6.23-rc1) - A file of 1/3 the RAM size is created, mapped and frequently accessed (4 times). - The test is run multiple times (4 total) to time it's execution. - After the first run, other runs take much less time, because the file is cached. - A previously created file, 4 times the size of the RAM, is read or copied. - The test is re-run (2 times) to time it's execution. To test: $ make # ./use-once-test.sh Some big files will be created in your /tmp. They don't get erased after the test to speedup multiple runs. Results: - The test execution time greatly increase after reading or copying the large file. - Frequently used data got kick out of the page cache and replaced with useless read once data. - Both the read only and copy (read + write) cases don't work. I believe this clearly illustrate the slowdowns I experience after I copy large files around my system. All applications on my desktop are jerky for some moments after that. Watching a DVD is another example. Base test: 1st run: 0m8.958s 2nd run: 0m3.442s 3rd run: 0m3.452s 4th run: 0m3.443s Reading a large file test: 1st run: 0m8.997s 2nd run: 0m3.522s `/tmp/large_file' -> `/dev/null' 3rd run: 0m8.999s <<< page cache trashed 4th run: 0m3.440s Copying (using cp) a large file test: 1st run: 0m8.979s 2nd run: 0m3.442s `/tmp/large_file' -> `/tmp/large_file.copy' 3rd run: 0m13.814s <<< page cache trashed 4th run: 0m3.455s Copying (using fadvise_cp) a large file test: 1st run: 0m9.018s 2nd run: 0m3.444s Copying large file... 3rd run: 0m14.024s <<< page cache trashed 4th run: 0m3.449s Copying (using splice-cp) a large file test: 1st run: 0m8.977s 2nd run: 0m3.442s Copying large file... 3rd run: 0m14.118s <<< page cache trashed 4th run: 0m3.456s Possible solutions: Various patches to fix the use-once mechanisms were discussed in the past. Some more that 6 years ago and some more recently. http://lwn.net/2001/0726/a/2q.php3 http://lkml.org/lkml/2005/5/3/6 http://lkml.org/lkml/2006/7/17/192 http://lkml.org/lkml/2007/7/9/340 http://lkml.org/lkml/2007/7/21/219 (*1) (*1) I have tested Peter's patch with some success. It fix the read case, but no the copy case. Results: http://lkml.org/lkml/2007/7/24/527 Test programs and batch files are attached. - Eric
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int in;
int out;
int pagesize;
void *buf;
off_t pos;
if (argc != 3) {
printf("Usage: %s <src> <dest>\n", argv[0]);
return EXIT_FAILURE;
}
in = open(argv[1], O_RDONLY, 0);
out = open(argv[2], O_CREAT | O_WRONLY | O_TRUNC, 0666);
posix_fadvise(in, 0, 0, POSIX_FADV_SEQUENTIAL);
posix_fadvise(out, 0, 0, POSIX_FADV_SEQUENTIAL);
pagesize = getpagesize();
buf = malloc(pagesize);
pos = 0;
for (;;) {
ssize_t count;
count = read(in, buf, pagesize);
if (!count || count == -1)
break;
write(out, buf, count);
/* right usage pattern? */
posix_fadvise(in, pos, count, POSIX_FADV_NOREUSE);
posix_fadvise(out, pos, count, POSIX_FADV_NOREUSE);
pos += count;
}
free(buf);
close(in);
close(out);
return EXIT_SUCCESS;
}
all: gcc fadvise_cp.c -o fadvise_cp gcc working_set_simul.c -o working_set_simul
Attachment:
use-once-test.sh
Description: application/shellscript
#include <fcntl.h>
#include <memory.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int fd;
off_t size;
char *mapping;
unsigned r;
unsigned i;
if (argc != 2) {
printf("Usage: %s <file>\n", argv[0]);
return EXIT_FAILURE;
}
fd = open(argv[1], O_RDONLY, 0);
size = lseek(fd, 0, SEEK_END);
mapping = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
/* access (read) the file a couple of times*/
for (r = 0; r < 4; r++) {
for (i = 0; i < size; i++) {
char t = mapping[i];
}
}
munmap(mapping, size);
close(fd);
return EXIT_SUCCESS;
}
- Prev by Date: Re: [PATCH 0/3] readahead drop behind and size adjustment
- Next by Date: [BUG] fadvise POSIX_FADV_NOREUSE does nothing
- Previous by thread: bug in slab.c
- Next by thread: [BUG] fadvise POSIX_FADV_NOREUSE does nothing
- Index(es):
 |