arm L_PTE_XXX entry addition for Debugging purpose

Dhyan linuxdhyan at gmail.com
Thu Aug 2 05:33:57 EDT 2012


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 <bill4carson at 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 <bill4carson at gmail.com
>> <mailto:bill4carson at 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
>>         <bill4carson at gmail.com <mailto:bill4carson at gmail.com>
>>         <mailto:bill4carson at gmail.com <mailto:bill4carson at 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
>>         <bill4carson at gmail.com <mailto:bill4carson at gmail.com>
>>         <mailto:bill4carson at gmail.com <mailto:bill4carson at gmail.com>**>
>>         <mailto:bill4carson at gmail.com <mailto:bill4carson at gmail.com>
>>         <mailto:bill4carson at gmail.com <mailto:bill4carson at 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 at kernelnewbies.__**____org
>>         <mailto:Kernelnewbies@
>>         <mailto:Kernelnewbies@>__kerne**l__newbies.org<http://kernel__newbies.org>
>>         <http://kernelnewbies.org>
>>         <mailto:Kernelnewbies at __kernel**newbies.org<http://kernelnewbies.org>
>>         <mailto:Kernelnewbies@**kernelnewbies.org<Kernelnewbies at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120802/e505efe7/attachment-0001.html 


More information about the Kernelnewbies mailing list