The answer to the second problem is that when you mmap a device memory space(physical address) to the user space(virtual space). The system call of mmap in kernel function will construct the corresponding page table mapping in user process. Then you load/store on the virtual address, CPU will decode the virtual address to get the actual device physical address through tlb. (If tlb miss, cpu will fetch page table automatically if cpu have hardware page table walker or by OS tlb miss exception.) The general cache attribute of a device is non-cacheable so when cpu will not get the data of specific device from cache. The truth is that cpu will dispatch the address out to north bridge(in x86) or AHB controller(in arm) .Then north bridge/ahb controller deocde the address to know where to direct the request to which device controller. When the device controller get the request, it returns the data to north bridge/ahb controller, and then return to CPU, last you(process) get the data. 2010/9/21 Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>: > Hi... > > > On Mon, Sep 20, 2010 at 12:33, Rajat Jain <rajatjain@xxxxxxxxxxx> wrote: >> 1) If the backing file is /dev/mem or a device file, then at the time of mmap(), the page table entries / TLB entries are set up such that the virtual address in the user space, maps to the actual physical address desired. And the thus job is done. This case is clear. > > I think what you mean here is anonymous mapping. > >> 2) The other case is that when the file is actually a datafile present in a file system lets say on a SATA disk. Now, for each load / store in the application, some driver code needs to trigger that will program the SATA controller registers and do n number of thinks to initiate the diska read / write transaction. How is this achieved? Because application is not making any System calls. Its just having load / store instructions. > > I'm not really sure about the point of the above question, but I will > take it literally. > > For file backed mmap, read/write (or in your term, load/store), could > mean two things: triggerring hard page fault, that is when the content > of the file is not in page cache..or directly reading it from the page > cache. > > So, the key here is the page fault. > > > -- > 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 > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
