[linux-mm-cc] Compcache as Ramdisk

[Vijayendra Suman]

Hi,

I want to use compcache 0.3 release as ramfs, which could be used for
processes for shred memory communication.
Currently, I compcache acts as virtual block driver and act as swap
Filesystem

1) swapoff compcache partition
2) mkfs.vfat -F 32 -S 4096 /dev/ramzswap0
3) mount /dev/ramzswap0 /mnt

I tried with a simple Filesystem test called bonnie you can get a copy from
                         http://www.garloff.de/kurt/linux/bonnie/

System hangs

./Boinnie -d /mnt -s 30

It will test the /mnt directory by creating upto 30MB data.

With Initial debugging I find this path hangs

sys_unlink (...)
do_unlinkat ( ATFDCWD, pathname)
iput(inode )
drop (inode )
generic_drop_inode()
generic_delete_inode(inode)
delete(inode)
truncate_inode_pages(&inode->i_data, 0)
truncate_inode_pages_range(mapping, lstart, (loff_t) -1)
     if (page->index > end)
      __wait_on_bit(page_waitqueue(page), &wait, sync_page);
           ret = (*action)(q->key.flags); // This action is the function
sync_page
sync_page()
  io_schedule()
    schedule()
      __schedule()

I have seen this issue in some of the versions of kernel like
2.6.18,20,20.1, on some architectures.

I will check this with 2.6.30 today let you know the issue.

I have used the lzo 1f version of compressor which allows me to boot an
application faster than 1x version.

Sincere Regards,
Vijayendra Suman


On Fri, Jun 5, 2009 at 11:30 AM, Vijayendra Suman <
vijayendra.suman at gmail.com> wrote:

> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/linux-mm-cc/attachments/20090710/92874fff/attachment.htm