Bug 79111

Summary: readahead fails with big file
Product: Memory Management Reporter: dlopezzz63
Component: OtherAssignee: 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:

Description dlopezzz63 2014-06-28 11:05:49 UTC
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
Comment 1 dlopezzz63 2014-06-28 11:19:46 UTC
It seems readahead is broken since upgrade from 3.14 to 3.15. Can't boot 3.14 now.
Comment 3 Jiri Jaburek 2014-10-06 09:55:51 UTC
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?