No subject

> 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 <nitingupta910 at gmail.com>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

--001e680f1b40ba325a046b939b87
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Nitin,<br><br>Nice to hear so early, :)<br><br><blockquote style=3D"bord=
er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l=
eft: 1ex;" class=3D"gmail_quote">At what point are you checking for this bi=
t - just before<br>

ramzswap_make_request()<br>
returns or somewhere else? How are you checking it?<br></blockquote><br>I p=
ut a breakpoint in __do_kernel_fault, This is called whenever there is page=
 fault with atomic context or from kernel thread.<br>I am only interested i=
n the atomic context wing execution.<br>
<br>I take the page table entry(pte) value, mm-&gt;pgd gives me the value a=
nd the faulting address which is the second parameter to this.<br>Arm has t=
wo copies PTE entry,<br>1) H/W pte<br>2) S/W pte<br>H/W pte lies 2kb below,=
 when i check this It is always 1 even when there is a page fault which mea=
n there was a exception even though the page was still lieing around in the=
 RAM.<br>
<br>Also i see both H/W and S/W pte copy is same which means both are in sy=
nc<br><br>I am not sure if the pte_present bit has any significance in the =
ARM&#39;s case, though i have seen the x86 manual it tells abt the it which=
 is why i am little confused.<br>
<br><blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin:=
 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote">From you desc=
ription, it looks like you *always* find this bit as set.<br>
If this is the case,<br>
then concurrent swap-in does not look like the reason for this.<br></blockq=
uote><br>Yes this is correct.<br><br><blockquote style=3D"border-left: 1px =
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" cl=
ass=3D"gmail_quote">
return value of 0 from ramzswap_make_request() means that the page is<br>
indeed swapped out. The pte_present bit can still be set due to concurrent<=
br>
swap-in as described above.<br></blockquote><br>I will find and let you kno=
w about it.<br><br>Thank You for your response.<br><br>Sincere Regards<br>V=
ijayendra Suman<br><br><br><div class=3D"gmail_quote">On Fri, Jun 5, 2009 a=
t 10:51 AM, Nitin Gupta <span dir=3D"ltr">&lt;<a href=3D"mailto:nitingupta9=
10 at gmail.com">nitingupta910 at gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Vijayendra,<br=
>
<div class=3D"im"><br>
&gt; The problem is even though i am able to see the swap in action but whe=
n i<br>
&gt; see the page pte_present flag it is still is one which means it is pre=
sent<br>
&gt; in the memory, so is it that the RAM block device is not setting this =
bit as<br>
&gt; 0 when the page is swapped.<br>
&gt;<br>
<br>
</div>RAM block device is not responsible for clearing this bit. When<br>
ramzswap_make_request()<br>
begins for a write request, the pte_present flag in corresponding PTE<br>
should have<br>
already been cleared by try_to_unuse().<br>
<br>
However, if a swap-in is triggered while swap-out is in process, the page<b=
r>
fault handler will map the corresponding PTE to page being swapped out<br>
(and hence<br>
set pte_present). So, even after swap-out (compression in our case) is<br>
completed,<br>
the PTE can still have pte_present set.<br>
<br>