Hi Himanshu... On Fri, Apr 9, 2010 at 00:31, Himanshu Aggarwal <lkml.himanshu@xxxxxxxxx> wrote: > I have read that mmap/mmap2 system calls are more efficient than a read and > a write system call. I am unable to understand why is this so? > mmap/mmap2 always create a vm_area_struct which is inserted into the > process's userspace region. Given that this is the case, how is mmap/mmap2 > more efficient than the read/write system call? Shouldn't it be less > efficient, because each access to mmapped region might be access this > vm_area_struct mapping? This is the way I see it. By using mmap/mmap2() instead of read/write, once you already map some part or the whole file, you can access simply by using memory address. Thus, for some people, it feels more "intuitive". Instead of read/write, when the part of a file isn't in RAM, page fault is triggered and they will be brought to RAM. in the end, it is almost similar like doing read/write, but again it's done "behind the screen" However, as you might predict, since it does memory mapping inside user address space, it could not exceed the free space left in the user address space . It could be even smaller due to memory space fragmentation > I have another doubt as well : if mmap/mmap2 are more efficient than a write > call, then why don't all drivers just implement a mmap file operation. Why > do they implement a write file-operation which is supposedly less efficient. > I have found only a few drivers implementing the mmap file operation. Is > there any reason for this? IMHO, the drivers that entirely rely on read/write are ones that operate or doesn't have any connection with user space. In kernel space, IIRC, mmap is avoided because it will trigger page fault, while page fault itself will force the code path to be blocked. And not all code path is sleep safe...e.g think about interrupt handler, inside spin lock etc. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
