arm L_PTE_XXX entry addition for Debugging purpose

[Dhyan]

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?

--
Thanks
Dhyan

On Wed, Aug 1, 2012 at 7:38 AM, bill4carson <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>**> 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@**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>
>> >
>>
>>
>>
>>     --
>>     Love each day!
>>
>>     --bill
>>
>>
>>
> --
> Love each day!
>
> --bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120801/7e331355/attachment.html