Messages in this thread | | | Date | Thu, 03 Jul 2008 10:57:53 +0900 (JST) | Subject | Re: follow_page() performance regressions | From | Hideo Saito <> |
| |
On Tue, 1 Jul 2008, Linus Torvalds wrote: > > I suspect it could be any of: > > - actual code generation differences in follow_page() (some SH person > needs to check that) > > - some cache issue on SH. ZERO_PAGE is a single page at a fixed virtual > address, while it used to populate the page tables with individual > pages. Normally, this should be *better* for caching, but maybe there > is some conflict? What kind of caches does SH have (virtually indexed?) > > - hackbench relying on follow_page() to populate the page tables, which > it no longer does for anonymous areas (using ZERO_PAGE directly > instead). > > Again, normally this would speed things up (fewer TLB misses etc), but > if it then causes a new page fault that used to have been covered by > follow_page(), who knows? > > What does hackbench actually do? Anybody?
I am reporter of this problem. Sorry, my testing was not enough. This problem depends our platform or maybe SH architecture.
When I changed that the code of |goto no_page| and |goto bad_page| to both |goto unlock| at follow_page(), I did not notice that the code of |bad_page:| and |no_page:| was lost by optimizer. In the result, only the size of the text code of kernel became small 0x40 bytes. I think that the cause of this problem is in any of our platform or in the replacement of SH cache.
| |