From: bill4carson@gmail.com (bill4carson)
To: kernelnewbies@lists.kernelnewbies.org
Subject: arm L_PTE_XXX entry addition for Debugging purpose
Date: Thu, 02 Aug 2012 16:42:44 +0800 [thread overview]
Message-ID: <501A3D84.7090105@gmail.com> (raw)
In-Reply-To: <CABFWu7YTqrrteGB8BawrGNyGLRE25OyrVvNoB9MqWWJx0y1CqA@mail.gmail.com>
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@gmail.com
> <mailto:bill4carson@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@gmail.com>
> <mailto:bill4carson at gmail.com <mailto:bill4carson@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
> <mailto:Kernelnewbies@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
>
>
--
Love each day!
--bill
next prev parent reply other threads:[~2012-08-02 8:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-30 9:39 arm L_PTE_XXX entry addition for Debugging purpose Dhyan
2012-07-31 7:13 ` bill4carson
2012-07-31 9:20 ` Dhyan
2012-08-01 2:08 ` bill4carson
2012-08-01 4:53 ` Dhyan
2012-08-01 5:57 ` Mulyadi Santosa
2012-08-01 6:17 ` Dhyan
2012-08-01 8:42 ` Mulyadi Santosa
2012-08-02 8:42 ` bill4carson [this message]
2012-08-02 9:03 ` Dhyan
2012-08-02 9:28 ` bill4carson
2012-08-02 9:33 ` Dhyan
-- strict thread matches above, loose matches on Subject: below --
2012-08-01 6:54 Vladimir Murzin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501A3D84.7090105@gmail.com \
--to=bill4carson@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).