* Why page fault handler behaved this way? Please help!
@ 2014-10-30 7:10 秦弋戈
2014-11-04 12:41 ` Mulyadi Santosa
0 siblings, 1 reply; 5+ messages in thread
From: 秦弋戈 @ 2014-10-30 7:10 UTC (permalink / raw)
To: kernelnewbies
Dear all,
I am a kernel newbie who want's to learn more about memory management. Recently I'm doing some experiment on page fault handler. There happened something that I couldn't understand.
>From reading the book Understanding the Linux Kernel, I know that the kernel loads a page as late as possible. It's only happened when the program has to reference??(read, write, or execute)?a page yet the page is not in memory.
However, when I traced all page faults in my test program, I found something strange. My test program is large enough, but there are only two page faults triggered in the code segment of the program, while most of the faults are not in code segment.
At first I thought that perhaps the page is not the normal 4K page. Thus I turned off the PAE support in the config file. But the log remains unchanged.
So why are there only 2 page faults in code segment? It shouldn't be like this in my opinion. Please help me.
The attachment is my kernel log. Limited by the mail size, I couldn't upload my program, but I believe that the log is clear enough.
Thank you very much.
Best regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel_log
Type: application/octet-stream
Size: 20722 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141030/52d3469a/attachment-0001.obj
^ permalink raw reply [flat|nested] 5+ messages in thread* Why page fault handler behaved this way? Please help! 2014-10-30 7:10 Why page fault handler behaved this way? Please help! 秦弋戈 @ 2014-11-04 12:41 ` Mulyadi Santosa 2014-11-04 13:13 ` Kirill A. Shutemov 0 siblings, 1 reply; 5+ messages in thread From: Mulyadi Santosa @ 2014-11-04 12:41 UTC (permalink / raw) To: kernelnewbies Hello... how big is your binary anyway? from your log, if my calculation is right, your code segment is around 330 KiB. But bear in mind, that not all of them are your code. There are other code like PLT, function prefix and so on. Also, even if your code is big, are you sure all of them are executed? Following 20/80 principle, most of the time, when running an application, only 20% portion of the application are really used/executed during 80% of application lifetime. The rest, it might untouched at all. On Thu, Oct 30, 2014 at 2:10 PM, ??? <michaelbest002@126.com> wrote: > > > > Dear all, > > > I am a kernel newbie who want's to learn more about memory management. > Recently I'm doing some experiment on page fault handler. There happened > something that I couldn't understand. > > > From reading the book Understanding the Linux Kernel, I know that the > kernel loads a page as late as possible. It's only happened when the > program has to reference (read, write, or execute) a page yet the page is > not in memory. > > > However, when I traced all page faults in my test program, I found > something strange. My test program is large enough, but there are only two > page faults triggered in the code segment of the program, while most of the > faults are not in code segment. > > > At first I thought that perhaps the page is not the normal 4K page. Thus I > turned off the PAE support in the config file. But the log remains > unchanged. > > > So why are there only 2 page faults in code segment? It shouldn't be like > this in my opinion. Please help me. > > > The attachment is my kernel log. Limited by the mail size, I couldn't > upload my program, but I believe that the log is clear enough. > > > Thank you very much. > Best regards > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141104/eaa2d41b/attachment-0001.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Why page fault handler behaved this way? Please help! 2014-11-04 12:41 ` Mulyadi Santosa @ 2014-11-04 13:13 ` Kirill A. Shutemov 2014-11-05 8:18 ` 秦弋戈 0 siblings, 1 reply; 5+ messages in thread From: Kirill A. Shutemov @ 2014-11-04 13:13 UTC (permalink / raw) To: kernelnewbies On Tue, Nov 04, 2014 at 07:41:08PM +0700, Mulyadi Santosa wrote: > Hello... > > how big is your binary anyway? > > from your log, if my calculation is right, your code segment is around 330 > KiB. But bear in mind, that not all of them are your code. There are other > code like PLT, function prefix and so on. > > Also, even if your code is big, are you sure all of them are executed? > Following 20/80 principle, most of the time, when running an application, > only 20% portion of the application are really used/executed during 80% of > application lifetime. The rest, it might untouched at all. > > > On Thu, Oct 30, 2014 at 2:10 PM, ??? <michaelbest002@126.com> wrote: > > > > > > > > > Dear all, > > > > > > I am a kernel newbie who want's to learn more about memory management. > > Recently I'm doing some experiment on page fault handler. There happened > > something that I couldn't understand. > > > > > > From reading the book Understanding the Linux Kernel, I know that the > > kernel loads a page as late as possible. It's only happened when the > > program has to reference (read, write, or execute) a page yet the page is > > not in memory. > > > > > > However, when I traced all page faults in my test program, I found > > something strange. My test program is large enough, but there are only two > > page faults triggered in the code segment of the program, while most of the > > faults are not in code segment. > > > > > > At first I thought that perhaps the page is not the normal 4K page. Thus I > > turned off the PAE support in the config file. But the log remains > > unchanged. > > > > > > So why are there only 2 page faults in code segment? It shouldn't be like > > this in my opinion. Please help me. We have "faultaround" feature in recent kernel which tries to map 64k with one page fault if the pages are already in page cache. There's handle in debugfs to disable the feature, if you want to play with this. > > The attachment is my kernel log. Limited by the mail size, I couldn't > > upload my program, but I believe that the log is clear enough. > > > > > > Thank you very much. > > Best regards > > > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 5+ messages in thread
* Why page fault handler behaved this way? Please help! 2014-11-04 13:13 ` Kirill A. Shutemov @ 2014-11-05 8:18 ` 秦弋戈 2014-11-05 14:58 ` Kirill A. Shutemov 0 siblings, 1 reply; 5+ messages in thread From: 秦弋戈 @ 2014-11-05 8:18 UTC (permalink / raw) To: kernelnewbies Hello, Thank you very much for helping me. Before I see your reply, I enlarged my program and I saw more page faults in code segment. Now I know there is something called fault-around. I read the Chapter 16 of the ULK which introduces file access. I started to know a technique called read-ahead from this chapter. So what's the difference or relationship between fault-around and read-ahead? I think they are used in different areas (layers) but have the same idea. Am I right? Best regards At 2014-11-04 21:13:56, "Kirill A. Shutemov" <kirill@shutemov.name> wrote: >On Tue, Nov 04, 2014 at 07:41:08PM +0700, Mulyadi Santosa wrote: >> Hello... >> >> how big is your binary anyway? >> >> from your log, if my calculation is right, your code segment is around 330 >> KiB. But bear in mind, that not all of them are your code. There are other >> code like PLT, function prefix and so on. >> >> Also, even if your code is big, are you sure all of them are executed? >> Following 20/80 principle, most of the time, when running an application, >> only 20% portion of the application are really used/executed during 80% of >> application lifetime. The rest, it might untouched at all. >> >> >> On Thu, Oct 30, 2014 at 2:10 PM, ??? <michaelbest002@126.com> wrote: >> >> > >> > >> > >> > Dear all, >> > >> > >> > I am a kernel newbie who want's to learn more about memory management. >> > Recently I'm doing some experiment on page fault handler. There happened >> > something that I couldn't understand. >> > >> > >> > From reading the book Understanding the Linux Kernel, I know that the >> > kernel loads a page as late as possible. It's only happened when the >> > program has to reference (read, write, or execute) a page yet the page is >> > not in memory. >> > >> > >> > However, when I traced all page faults in my test program, I found >> > something strange. My test program is large enough, but there are only two >> > page faults triggered in the code segment of the program, while most of the >> > faults are not in code segment. >> > >> > >> > At first I thought that perhaps the page is not the normal 4K page. Thus I >> > turned off the PAE support in the config file. But the log remains >> > unchanged. >> > >> > >> > So why are there only 2 page faults in code segment? It shouldn't be like >> > this in my opinion. Please help me. > >We have "faultaround" feature in recent kernel which tries to map 64k with >one page fault if the pages are already in page cache. There's handle in >debugfs to disable the feature, if you want to play with this. > >> > The attachment is my kernel log. Limited by the mail size, I couldn't >> > upload my program, but I believe that the log is clear enough. >> > >> > >> > Thank you very much. >> > Best regards >> > >> > >> > _______________________________________________ >> > Kernelnewbies mailing list >> > Kernelnewbies at kernelnewbies.org >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > >> > >> >> >> -- >> regards, >> >> Mulyadi Santosa >> Freelance Linux trainer and consultant >> >> blog: the-hydra.blogspot.com >> training: mulyaditraining.blogspot.com > >-- > Kirill A. Shutemov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141105/257884c2/attachment.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Why page fault handler behaved this way? Please help! 2014-11-05 8:18 ` 秦弋戈 @ 2014-11-05 14:58 ` Kirill A. Shutemov 0 siblings, 0 replies; 5+ messages in thread From: Kirill A. Shutemov @ 2014-11-05 14:58 UTC (permalink / raw) To: kernelnewbies On Wed, Nov 05, 2014 at 04:18:36PM +0800, ??? wrote: > Hello, > > > Thank you very much for helping me. Before I see your reply, I enlarged > my program and I saw more page faults in code segment. Now I know there > is something called fault-around. > > > I read the Chapter 16 of the ULK which introduces file access. I started > to know a technique called read-ahead from this chapter. So what's the > difference or relationship between fault-around and read-ahead? I think > they are used in different areas (layers) but have the same idea. Am I > right? readahead reads data from backing storage to page-cache, but it doesn't map it to process' address space. fault-around maps pages which already in page cache: via readahead or not. -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-11-05 14:58 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-30 7:10 Why page fault handler behaved this way? Please help! 秦弋戈 2014-11-04 12:41 ` Mulyadi Santosa 2014-11-04 13:13 ` Kirill A. Shutemov 2014-11-05 8:18 ` 秦弋戈 2014-11-05 14:58 ` Kirill A. Shutemov
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).