Bug 79111
| Summary: | readahead fails with big file | ||
|---|---|---|---|
| Product: | Memory Management | Reporter: | dlopezzz63 |
| Component: | Other | Assignee: | Andrew Morton (akpm) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | jiri.jabu |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.15.2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
It seems readahead is broken since upgrade from 3.14 to 3.15. Can't boot 3.14 now. readahead is broken because of following commit https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/mm/readahead.c?id=6d2be915e589b58cb11418cbe1f22ff90732b6ac Also discussed on lkml, https://lkml.org/lkml/2014/7/3/416. There are perhaps two separate issues: - readahead() blocking / not blocking - readahead() not reading 'count' bytes The first one seems to be a documentation issue as, apparently, readahead() was never meant to block for the entire duration of readahead, http://www.spinics.net/lists/linux-mm/msg70517.html. The second one still remains (AFAIK) open, as (for 3.15+) the kernel basically throws away the user-provided 'count' argument and reads some default (be that 2MB, 16MB, 256MB or whatever else). Which - assuming this was always the intended behavior - leads me to question the meaning of the readahead() syscall. Is it really supposed to be "for anything up to $default, use readahead(), else use read() in a separate fork/thread"? It kind of seems like a workaround to me. Should new/maintained applications use readahead() or avoid it entirely? |
readahead fails with 950 MB file #define _GNU_SOURCE #include <fcntl.h> #include <stdio.h> int main() { const int size = 1 * 1024 * 1024 * 1024; int fd = open("950MB.iso",O_RDONLY); int res = readahead(fd, 0, size); printf("%d %d\n",fd,res); close(fd); } output: 3 0 meminfo after "echo 3 > drop_caches" and running of above code MemTotal: 8072248 kB MemFree: 7535972 kB MemAvailable: 7643860 kB Buffers: 33036 kB Cached: 220184 kB