Hi, <br><br>I want to use compcache 0.3 release as ramfs, which could be used for processes for shred memory communication.<br>Currently, I compcache acts as virtual block driver and act as swap Filesystem<br><br>1) swapoff compcache partition<br>
2) mkfs.vfat -F 32 -S 4096 /dev/ramzswap0<br>3) mount /dev/ramzswap0 /mnt <br><br>I tried with a simple Filesystem test called bonnie you can get a copy from <br> <a href="http://www.garloff.de/kurt/linux/bonnie/">http://www.garloff.de/kurt/linux/bonnie/</a><br>
<br>System hangs<br><br>./Boinnie -d /mnt -s 30<br><br>It will test the /mnt directory by creating upto 30MB data.<br><br>With Initial debugging I find this path hangs<br><br>sys_unlink (...)<br>do_unlinkat ( ATFDCWD, pathname)<br>
iput(inode )<br>drop (inode ) <br>generic_drop_inode()<br>generic_delete_inode(inode)<br>delete(inode)<br>truncate_inode_pages(&inode->i_data, 0)<br>truncate_inode_pages_range(mapping, lstart, (loff_t) -1)<br> if (page->index > end)<br>
__wait_on_bit(page_waitqueue(page), &wait, sync_page);<br> ret = (*action)(q->key.flags); // This action is the function sync_page<br>sync_page()<br> io_schedule()<br> schedule()<br> __schedule()<br>
<br>I have seen this issue in some of the versions of kernel like 2.6.18,20,20.1, on some architectures.<br><br>I will check this with 2.6.30 today let you know the issue.<br><br>I have used the lzo 1f version of compressor which allows me to boot an application faster than 1x version.<br>
<br>Sincere Regards, <br>Vijayendra Suman<br><br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 11:30 AM, Vijayendra Suman <span dir="ltr"><<a href="mailto:vijayendra.suman@gmail.com">vijayendra.suman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Nitin,<br><br>Nice to hear so early, :)<div class="im"><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
At what point are you checking for this bit - just before<br>
ramzswap_make_request()<br>
returns or somewhere else? How are you checking it?<br></blockquote><br></div>I put 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 in the atomic context wing execution.<br>
<br>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.<br>Arm has two 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 mean 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 sync<br><br>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.<div class="im">
<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">From you description, 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></blockquote><br></div>Yes this is correct.<div class="im"><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="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></div>I will find and let you know about it.<br><br>Thank You for your response.<br><br>Sincere Regards<br>Vijayendra Suman<div><div></div><div class="h5"><br><br><br><div class="gmail_quote">
On Fri, Jun 5, 2009 at 10:51 AM, Nitin Gupta <span dir="ltr"><<a href="mailto:nitingupta910@gmail.com" target="_blank">nitingupta910@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Vijayendra,<br>
<div><br>
> The problem is even though i am able to see the swap in action but when i<br>
> see the page pte_present flag it is still is one which means it is present<br>
> in the memory, so is it that the RAM block device is not setting this bit as<br>
> 0 when the page is swapped.<br>
><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<br>
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>