I will dump all the written pages of the application and run a garbage collection algorithm over the dumped contents.
Thanks Dhyan On Thu, Aug 2, 2012 at 2:58 PM, bill4carson <bill4car...@gmail.com> wrote: > > > On 2012年08月02日 17:03, Dhyan wrote: > >> Dear Bill, >> >> What i found from experimenting on arm Linux kernel is ,after every >> access if i clear the _PG_ACCESS bit of the pte (using >> /proc/<pid>/clear_refs),the next write also will come to kernel >> (handle_pte_fault).But I dont know whether my clearing action causing >> any bad impact on any other system. >> >> > 592 static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr, > 593 unsigned long end, struct mm_walk *walk) > 594 { > 595 struct vm_area_struct *vma = walk->private; > 596 pte_t *pte, ptent; > 597 spinlock_t *ptl; > 598 struct page *page; > 599 > 600 split_huge_page_pmd(walk->mm, pmd); > 601 if (pmd_trans_unstable(pmd)) > 602 return 0; > 603 > 604 pte = pte_offset_map_lock(vma->vm_**mm, pmd, addr, &ptl); > 605 for (; addr != end; pte++, addr += PAGE_SIZE) { > 606 ptent = *pte; > 607 if (!pte_present(ptent)) > 608 continue; > 609 > 610 page = vm_normal_page(vma, addr, ptent); > 611 if (!page) > 612 continue; > 613 > 614 /* Clear accessed and referenced bits. */ > 615 ptep_test_and_clear_young(vma, addr, pte); > ^^^^^^^^^^^^ > For arm, it clear all the corresponding pte entries. > that's why you got second page fault. > > Again, I don't understand your original purpose > >> -- >> Thanks >> Dhyan >> >> On Thu, Aug 2, 2012 at 2:12 PM, bill4carson <bill4car...@gmail.com >> <mailto:bill4car...@gmail.com>**> wrote: >> >> >> >> On 2012年08月01日 12:53, Dhyan wrote: >> >> Dear Bill, >> >> Thank you for spending your valuable time for understanding and >> answering my queries !!! >> >> I was trying to apply some garbage collection algorithm on this >> dumped >> pages,thats why i want only the written pages. >> >> Sorry to ask,but is there any other good way to find the written >> pages >> of a user process? >> >> >> Only the first wirte trigger page fault, which setup the page table by >> grabbing a physical page to backup virtual address page. After this, >> all write into that page goes like wind without any kernel >> interference >> anymore. >> >> >> But my hunch tell me what you want is to track every user space write >> operation. >> >> >> >> -- >> Thanks >> Dhyan >> >> On Wed, Aug 1, 2012 at 7:38 AM, bill4carson >> <bill4car...@gmail.com <mailto:bill4car...@gmail.com> >> <mailto:bill4car...@gmail.com <mailto:bill4car...@gmail.com>** >> >__> >> wrote: >> >> >> >> On 2012年07月31日 17:20, Dhyan wrote: >> >> Thank You Bill !!! >> >> I dont know my approach is correct or not,But the >> actual purpose >> was to >> dump only written pages of a user process using a kernel >> module.I have >> a kernel thread which will dump user process memory in >> specific >> interval.So i thought of updating this flag >> (L_PTE_DEBUG) from >> handle_pte_fault and clear from my clear thread so that >> i can >> dump only >> the written pages after my last dump. >> >> >> Yes, you can do that, only if your accounting memory >> doesn't get swapped >> out. >> >> If I understand correctly, when writing a page, you mark >> corresponding >> linux pte entry with L_PTE_DEBUG. Then your kernel module >> periodically >> loops all linux pte table, find pte entry marked with >> L_PTE_DEBUG..... >> >> I don't think it's wise to do so, you have 768 1st level >> pgd entries >> for user space, followed by 256 pte entries with each pgd >> entry. >> it's much slower to find out the right one. >> >> moreover, you probably need to remap those L_PTE_DEBUG >> physical pages >> into your own current process address space. IMHO, I don't >> follow >> such idea could be feasible. >> >> >> >> if you have some suggestions could you please share >> wth me? >> >> >> I understand how you plan to do this, could I ask why you >> need to dump >> the written pages? >> >> >> -- >> Thanks >> Dhyan >> >> On Tue, Jul 31, 2012 at 12:43 PM, bill4carson >> <bill4car...@gmail.com <mailto:bill4car...@gmail.com> >> <mailto:bill4car...@gmail.com <mailto:bill4car...@gmail.com>**> >> <mailto:bill4car...@gmail.com <mailto:bill4car...@gmail.com> >> <mailto:bill4car...@gmail.com <mailto:bill4car...@gmail.com>** >> >__>__> >> >> >> wrote: >> >> >> >> On 2012年07月30日 17:39, Dhyan wrote: >> >> Dear All, >> >> From linux(2.6.35) arm page table >> architecture i can >> see we >> have one >> hardware page table and there is >> corresponding Linux >> page table >> Entry >> (L_PTE_*).The "Linux" PTE definitions are as >> like below >> from >> arch/arm/include/asm/pgtable._**_____h. >> >> >> >> >> |#define L_PTE_PRESENT (1<< 0) >> #define L_PTE_FILE (1<< 1) >> #define L_PTE_YOUNG (1<< 1) >> #define L_PTE_BUFFERABLE(1<< 2) >> #define L_PTE_CACHEABLE (1<< 3) >> #define L_PTE_USER (1<< 4) >> #define L_PTE_WRITE (1<< 5) >> #define L_PTE_EXEC (1<< 6) >> #define L_PTE_DIRTY (1<< 7) >> #define L_PTE_COHERENT (1<< 9) >> #define L_PTE_SHARED (1<< 10) >> | >> >> So is it possible to add one more #|define >> L_PTE_DEBUG >> (1 << >> 11)| for my >> >> debugging purpose (basically to trap all the >> write to >> that page >> and set >> this bit when write happens and clear it off >> in another >> thread >> )? Or >> is there any limitation like we can use only >> L_PTE till >> 10th bit ? >> >> >> No such limitation on bit 11, so you can use define >> L_PTE_DEBUG (1 >> << 11) >> However I don't follow why you want to do so? >> >> >> So could you please help >> >> -- >> >> Thanks & Regards >> >> Dhayn >> >> >> >> >> ______________________________**_______________________ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.__**____org >> <mailto:Kernelnewbies@ >> >> <mailto:Kernelnewbies@>__kerne**l__newbies.org<http://kernel__newbies.org> >> <http://kernelnewbies.org> >> <mailto:Kernelnewbies@__kernel**newbies.org<http://kernelnewbies.org> >> >> <mailto:Kernelnewbies@**kernelnewbies.org<Kernelnewbies@kernelnewbies.org> >> >>> >> http://lists.kernelnewbies.___**___org/mailman/listinfo/______** >> kernelnewbies >> >> >> <http://lists.kernelnewbies.__**__org/mailman/listinfo/____** >> kernelnewbies >> <http://lists.kernelnewbies.__**org/mailman/listinfo/__** >> kernelnewbies >> <http://lists.kernelnewbies.**org/mailman/listinfo/** >> kernelnewbies<http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies> >> >>> >> >> >> >> -- >> Love each day! >> >> --bill >> >> >> >> -- >> Love each day! >> >> --bill >> >> >> >> -- >> Love each day! >> >> --bill >> >> >> > -- > Love each day! > > --bill >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies