Hi Nitin, Nice to hear so early, :)
At what point are you checking for this bit - just before > ramzswap_make_request() > returns or somewhere else? How are you checking it? > I put a breakpoint in __do_kernel_fault, This is called whenever there is page fault with atomic context or from kernel thread. I am only interested in the atomic context wing execution. I take the page table entry(pte) value, mm->pgd gives me the value and the faulting address which is the second parameter to this. Arm has two copies PTE entry, 1) H/W pte 2) S/W pte H/W pte lies 2kb below, when i check this It is always 1 even when there is a page fault which mean there was a exception even though the page was still lieing around in the RAM. Also i see both H/W and S/W pte copy is same which means both are in sync I am not sure if the pte_present bit has any significance in the ARM's case, though i have seen the x86 manual it tells abt the it which is why i am little confused. >From you description, it looks like you *always* find this bit as set. > If this is the case, > then concurrent swap-in does not look like the reason for this. > Yes this is correct. return value of 0 from ramzswap_make_request() means that the page is > indeed swapped out. The pte_present bit can still be set due to concurrent > swap-in as described above. > I will find and let you know about it. Thank You for your response. Sincere Regards Vijayendra Suman On Fri, Jun 5, 2009 at 10:51 AM, Nitin Gupta <[email protected]>wrote: > Hi Vijayendra, > > > The problem is even though i am able to see the swap in action but when i > > see the page pte_present flag it is still is one which means it is > present > > in the memory, so is it that the RAM block device is not setting this bit > as > > 0 when the page is swapped. > > > > RAM block device is not responsible for clearing this bit. When > ramzswap_make_request() > begins for a write request, the pte_present flag in corresponding PTE > should have > already been cleared by try_to_unuse(). > > However, if a swap-in is triggered while swap-out is in process, the page > fault handler will map the corresponding PTE to page being swapped out > (and hence > set pte_present). So, even after swap-out (compression in our case) is > completed, > the PTE can still have pte_present set. > > From you description, it looks like you *always* find this bit as set. > If this is the case, > then concurrent swap-in does not look like the reason for this. > > > > > I can give a better detailed question/problem if the above is not clear. > > At what point are you checking for this bit - just before > ramzswap_make_request() > returns or somewhere else? How are you checking it? > > > > > Please feel free to give me suggestion how can i verify if the page is > > actaully able to swap out to the swap device node in our case it is on > RAM. > > > > return value of 0 from ramzswap_make_request() means that the page is > indeed swapped out. The pte_present bit can still be set due to concurrent > swap-in as described above. > > Thanks, > Nitin > -- https://mail.google.com/mail/?ui=2&view=bsp&ver=1qygpcgurkovy Regards Vijayendra Suman
_______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
