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 _______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
