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.
-- Thanks Dhyan On Thu, Aug 2, 2012 at 2:12 PM, bill4carson <[email protected]> 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 <[email protected] >> <mailto:[email protected]>**> 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 >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>** >> >__> >> >> 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@__kernel**newbies.org<http://kernelnewbies.org> >> >> <mailto:Kernelnewbies@**kernelnewbies.org<[email protected]> >> >> >> 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 >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
