1

In the Linux kernel, is open(), mmap() or neither, the more fundamental way to access a file? By "fundamental", I mean "does either ultimately call the other or a simple helper function of the other?".

There are a lot of questions on the stack network asking about the performance of these two functions. The hope of this question is to get at what is going on inside the Linux kernel a priori. Does open() call mmap() or some helper function that essentially implements mmap()? Alternatively, does mmap() call open() or call some helper function that essentially implements open()?

The gist of the question is whether these two system calls are fundamentally different or whether one is a "convenience function" of the other.

0

2 Answers 2

5

Notice that mmap(2) often wants a file descriptor usually provided by open(2); in that sense, open is more fundamental. Notice also that the virtual address space of some process is modified not only by mmap, munmap, mprotect(2) but also by other system calls (including execve(2); see also shm_overview(7))

BTW, the Linux kernel don't use mmap or open but provides and implements them (for application-level user-space programs).

But the Linux kernel manages the page cache which is more fundamental and related to both system calls. See also LinuxAteMyRam and consider perhaps using madvise(2), posix_fadvise(2), readahead(2) to give hints to the page cache subsystem.

whether these two system calls are fundamentally different

All system calls (listed in syscalls(2)...) are different.

Read also Advanced Linux Programming and Operating Systems : Three Easy Pieces (both are freely downloadable).

3
  • Thank for pointing out mmap() wanting a file descriptor from open(). I guess I should have said open() + read()/write() vs mmap() + read()/write()? Aug 11, 2017 at 7:06
  • 1
    @Praxeolitic, the point of mmap() is that you don't use read()/write() to access the file's data, the data is mapped in the process' address space (pulled on-demand from the file by the kernel through the MMU's page fault mechanism instead of the user explicitely requesting the kernel with a read() system call) Aug 11, 2017 at 9:07
  • @StéphaneChazelas Oops. I should have said mmap() + reading/writing. Aug 11, 2017 at 23:57
2

Since you're naming functions, we assume you already know that calling mmap() on a file requires an fd, which is typically (but not always) created with open().

Unless you use O_DIRECT, in kernels like Linux with a "unified buffer cache", read() and write() operate on the same page cache which is mapped in by mmap(). However this ignores the performance tradeoffs of each method, so it does not seem a very useful answer.

Outside of obtaining a book, Google finds a nice and short description of mmap and regular IO v.s. the page cache. It does not mention the performance costs of mmap(), as per the quote from Linus Torvalds which you've probably already seen.

3
  • I will read your link (I've encountered that site before and it's excellent). In the mean time (I'll probably sleep ~8 hrs before I read the link), is there anything I should specify to help narrow down the question to one with a more definitive answer? For example, would specifying "sequential reading of an entire file" help? Aug 11, 2017 at 7:00
  • Also, if you were to suggest obtaining a book, what would it be? Thanks. Aug 11, 2017 at 7:09
  • @Praxeolitic Not sure, I mostly said that because I got a Safari link in my search results :).
    – sourcejedi
    Aug 11, 2017 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.