Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420106 > unrolled thread

Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression "Huang\, Ying" <ying.huang@intel.com> - 2016-06-12 02:50 +0200
    Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-12 03:10 +0200
      Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression "Huang\, Ying" <ying.huang@intel.com> - 2016-06-13 11:10 +0200
        Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression Minchan Kim <minchan@kernel.org> - 2016-06-14 15:40 +0200
          Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression "Huang\, Ying" <ying.huang@intel.com> - 2016-06-16 01:50 +0200
      Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-06-13 15:00 +0200
        Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-14 08:20 +0200
          Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-06-14 10:30 +0200
            Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression Rik van Riel <riel@redhat.com> - 2016-06-14 18:10 +0200
          Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression Christian Borntraeger <borntraeger@de.ibm.com> - 2016-06-14 16:10 +0200

#1420106 — Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression

"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:

> On Wed, Jun 08, 2016 at 04:41:37PM +0800, Huang, Ying wrote:
>> "Huang, Ying" <ying.huang@intel.com> writes:
>> 
>> > "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:
>> >
>> >> On Mon, Jun 06, 2016 at 10:27:24AM +0800, kernel test robot wrote:
>> >>> 
>> >>> FYI, we noticed a -6.3% regression of unixbench.score due to commit:
>> >>> 
>> >>> commit 5c0a85fad949212b3e059692deecdeed74ae7ec7 ("mm: make faultaround produce old ptes")
>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> >>> 
>> >>> in testcase: unixbench
>> >>> on test machine: lituya: 16 threads Haswell High-end Desktop (i7-5960X 3.0G) with 16G memory
>> >>> with following parameters: cpufreq_governor=performance/nr_task=1/test=shell8
>> >>> 
>> >>> 
>> >>> Details are as below:
>> >>> -------------------------------------------------------------------------------------------------->
>> >>> 
>> >>> 
>> >>> =========================================================================================
>> >>> compiler/cpufreq_governor/kconfig/nr_task/rootfs/tbox_group/test/testcase:
>> >>>   gcc-4.9/performance/x86_64-rhel/1/debian-x86_64-2015-02-07.cgz/lituya/shell8/unixbench
>> >>> 
>> >>> commit: 
>> >>>   4b50bcc7eda4d3cc9e3f2a0aa60e590fedf728c5
>> >>>   5c0a85fad949212b3e059692deecdeed74ae7ec7
>> >>> 
>> >>> 4b50bcc7eda4d3cc 5c0a85fad949212b3e059692de 
>> >>> ---------------- -------------------------- 
>> >>>        fail:runs  %reproduction    fail:runs
>> >>>            |             |             |    
>> >>>           3:4          -75%            :4     kmsg.DHCP/BOOTP:Reply_not_for_us,op[#]xid[#]
>> >>>          %stddev     %change         %stddev
>> >>>              \          |                \  
>> >>>      14321 .  0%      -6.3%      13425 .  0%  unixbench.score
>> >>>    1996897 .  0%      -6.1%    1874635 .  0%  unixbench.time.involuntary_context_switches
>> >>>  1.721e+08 .  0%      -6.2%  1.613e+08 .  0%  unixbench.time.minor_page_faults
>> >>>     758.65 .  0%      -3.0%     735.86 .  0%  unixbench.time.system_time
>> >>>     387.66 .  0%      +5.4%     408.49 .  0%  unixbench.time.user_time
>> >>>    5950278 .  0%      -6.2%    5583456 .  0%  unixbench.time.voluntary_context_switches
>> >>
>> >> That's weird.
>> >>
>> >> I don't understand why the change would reduce number or minor faults.
>> >> It should stay the same on x86-64. Rise of user_time is puzzling too.
>> >
>> > unixbench runs in fixed time mode.  That is, the total time to run
>> > unixbench is fixed, but the work done varies.  So the minor_page_faults
>> > change may reflect only the work done.
>> >
>> >> Hm. Is reproducible? Across reboot?
>> >
>> 
>> And FYI, there is no swap setup for test, all root file system including
>> benchmark files are in tmpfs, so no real page reclaim will be
>> triggered.  But it appears that active file cache reduced after the
>> commit.
>> 
>>     111331 .  1%     -13.3%      96503 .  0%  meminfo.Active
>>      27603 .  1%     -43.9%      15486 .  0%  meminfo.Active(file)
>> 
>> I think this is the expected behavior of the commit?
>
> Yes, it's expected.
>
> After the change faularound would produce old pte. It means there's more
> chance for these pages to be on inactive lru, unless somebody actually
> touch them and flip accessed bit.
>
> I wounder if this regression can attributed to cost of setting accessed
> bit. It looks too high, but who knows.

From perf profile, the time spent in page_fault and its children
functions are almost same (7.85% vs 7.81%).  So the time spent in page
fault and page table operation itself doesn't changed much.  So, you
mean CPU may be slower to load the page table entry to TLB if accessed
bit is not set?

> I don't have time to do testing myself right now. I will put this on todo
> list.

Which kind of test your want to do?  I want to check whether I can help.

Best Regards,
Huang, Ying

[toc] | [next] | [standalone]

#1420110

On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying <ying.huang@intel.com> wrote:
>
> From perf profile, the time spent in page_fault and its children
> functions are almost same (7.85% vs 7.81%).  So the time spent in page
> fault and page table operation itself doesn't changed much.  So, you
> mean CPU may be slower to load the page table entry to TLB if accessed
> bit is not set?

So the CPU does take a microfault internally when it needs to set the
accessed/dirty bit. It's not architecturally visible, but you can see
it when you do timing loops.

I've timed it at over a thousand cycles on at least some CPU's, but
that's still peanuts compared to a real page fault. It shouldn't be
*that* noticeable, ie no way it's a 6% regression on its own.

           Linus

[toc] | [prev] | [next] | [standalone]

#1420641

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying <ying.huang@intel.com> wrote:
>>
>> From perf profile, the time spent in page_fault and its children
>> functions are almost same (7.85% vs 7.81%).  So the time spent in page
>> fault and page table operation itself doesn't changed much.  So, you
>> mean CPU may be slower to load the page table entry to TLB if accessed
>> bit is not set?
>
> So the CPU does take a microfault internally when it needs to set the
> accessed/dirty bit. It's not architecturally visible, but you can see
> it when you do timing loops.
>
> I've timed it at over a thousand cycles on at least some CPU's, but
> that's still peanuts compared to a real page fault. It shouldn't be
> *that* noticeable, ie no way it's a 6% regression on its own.

I done some simple counting, and found that about 3.15e9 PTE are set to
old during the test after the commit.  This may interpret the user_time
increase as below, because these accessed bit microfault is accounted as
user time.

    387.66 .  0%      +5.4%     408.49 .  0%  unixbench.time.user_time

I also make a one line debug patch as below on top of the commit to set
the PTE to young unconditionally, which recover the regression.

modified   mm/filemap.c
@@ -2193,7 +2193,7 @@ repeat:
 		if (file->f_ra.mmap_miss > 0)
 			file->f_ra.mmap_miss--;
 		addr = address + (page->index - vmf->pgoff) * PAGE_SIZE;
-		do_set_pte(vma, addr, page, pte, false, false, true);
+		do_set_pte(vma, addr, page, pte, false, false, false);
 		unlock_page(page);
 		atomic64_inc(&old_pte_count);
 		goto next;

Best Regards,
Huang, Ying

[toc] | [prev] | [next] | [standalone]

#1421908

On Mon, Jun 13, 2016 at 05:02:15PM +0800, Huang, Ying wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying <ying.huang@intel.com> wrote:
> >>
> >> From perf profile, the time spent in page_fault and its children
> >> functions are almost same (7.85% vs 7.81%).  So the time spent in page
> >> fault and page table operation itself doesn't changed much.  So, you
> >> mean CPU may be slower to load the page table entry to TLB if accessed
> >> bit is not set?
> >
> > So the CPU does take a microfault internally when it needs to set the
> > accessed/dirty bit. It's not architecturally visible, but you can see
> > it when you do timing loops.
> >
> > I've timed it at over a thousand cycles on at least some CPU's, but
> > that's still peanuts compared to a real page fault. It shouldn't be
> > *that* noticeable, ie no way it's a 6% regression on its own.
> 
> I done some simple counting, and found that about 3.15e9 PTE are set to
> old during the test after the commit.  This may interpret the user_time
> increase as below, because these accessed bit microfault is accounted as
> user time.
> 
>     387.66 .  0%      +5.4%     408.49 .  0%  unixbench.time.user_time
> 
> I also make a one line debug patch as below on top of the commit to set
> the PTE to young unconditionally, which recover the regression.

With this patch, meminfo.Active(file) is almost same unlike previous
experiment?

> 
> modified   mm/filemap.c
> @@ -2193,7 +2193,7 @@ repeat:
>  		if (file->f_ra.mmap_miss > 0)
>  			file->f_ra.mmap_miss--;
>  		addr = address + (page->index - vmf->pgoff) * PAGE_SIZE;
> -		do_set_pte(vma, addr, page, pte, false, false, true);
> +		do_set_pte(vma, addr, page, pte, false, false, false);
>  		unlock_page(page);
>  		atomic64_inc(&old_pte_count);
>  		goto next;
> 
> Best Regards,
> Huang, Ying

[toc] | [prev] | [next] | [standalone]

#1423583

Minchan Kim <minchan@kernel.org> writes:

> On Mon, Jun 13, 2016 at 05:02:15PM +0800, Huang, Ying wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> 
>> > On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying <ying.huang@intel.com> wrote:
>> >>
>> >> From perf profile, the time spent in page_fault and its children
>> >> functions are almost same (7.85% vs 7.81%).  So the time spent in page
>> >> fault and page table operation itself doesn't changed much.  So, you
>> >> mean CPU may be slower to load the page table entry to TLB if accessed
>> >> bit is not set?
>> >
>> > So the CPU does take a microfault internally when it needs to set the
>> > accessed/dirty bit. It's not architecturally visible, but you can see
>> > it when you do timing loops.
>> >
>> > I've timed it at over a thousand cycles on at least some CPU's, but
>> > that's still peanuts compared to a real page fault. It shouldn't be
>> > *that* noticeable, ie no way it's a 6% regression on its own.
>> 
>> I done some simple counting, and found that about 3.15e9 PTE are set to
>> old during the test after the commit.  This may interpret the user_time
>> increase as below, because these accessed bit microfault is accounted as
>> user time.
>> 
>>     387.66 .  0%      +5.4%     408.49 .  0%  unixbench.time.user_time
>> 
>> I also make a one line debug patch as below on top of the commit to set
>> the PTE to young unconditionally, which recover the regression.
>
> With this patch, meminfo.Active(file) is almost same unlike previous
> experiment?

Yes.  meminfo.Active(file) is almost same of that of the parent commit of
the first bad commit.

Best Regards,
Huang, Ying

>> 
>> modified   mm/filemap.c
>> @@ -2193,7 +2193,7 @@ repeat:
>>  		if (file->f_ra.mmap_miss > 0)
>>  			file->f_ra.mmap_miss--;
>>  		addr = address + (page->index - vmf->pgoff) * PAGE_SIZE;
>> -		do_set_pte(vma, addr, page, pte, false, false, true);
>> +		do_set_pte(vma, addr, page, pte, false, false, false);
>>  		unlock_page(page);
>>  		atomic64_inc(&old_pte_count);
>>  		goto next;
>> 
>> Best Regards,
>> Huang, Ying

[toc] | [prev] | [next] | [standalone]

#1420802

On Sat, Jun 11, 2016 at 06:02:57PM -0700, Linus Torvalds wrote:
> On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying <ying.huang@intel.com> wrote:
> >
> > From perf profile, the time spent in page_fault and its children
> > functions are almost same (7.85% vs 7.81%).  So the time spent in page
> > fault and page table operation itself doesn't changed much.  So, you
> > mean CPU may be slower to load the page table entry to TLB if accessed
> > bit is not set?
> 
> So the CPU does take a microfault internally when it needs to set the
> accessed/dirty bit. It's not architecturally visible, but you can see
> it when you do timing loops.
> 
> I've timed it at over a thousand cycles on at least some CPU's, but
> that's still peanuts compared to a real page fault. It shouldn't be
> *that* noticeable, ie no way it's a 6% regression on its own.

Looks like setting accessed bit is the problem.

Withouth mkold:

Score: 1952.9

  Performance counter stats for './Run shell8 -c 1' (3 runs):
 
    468,562,316,621      cycles:u                                                      ( +-  0.02% )
      4,596,299,472      dtlb_load_misses_walk_duration:u                                     ( +-  0.07% )
      5,245,488,559      itlb_misses_walk_duration:u                                     ( +-  0.10% )
 
      189.336404566 seconds time elapsed                                          ( +-  0.01% )

With mkold:

Score: 1885.5

  Performance counter stats for './Run shell8 -c 1' (3 runs):
 
    503,185,676,256      cycles:u                                                      ( +-  0.06% )
      8,137,007,894      dtlb_load_misses_walk_duration:u                                     ( +-  0.85% )
      7,220,632,283      itlb_misses_walk_duration:u                                     ( +-  1.40% )
 
      189.363223499 seconds time elapsed                                          ( +-  0.01% )

We spend 36% more time in page walk only, about 1% of total userspace time.
Combining this with page walk footprint on caches, I guess we can get to
this 3.5% score difference I see.

I'm not sure if there's anything we can do to solve the issue without
screwing relacim logic again. :(

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1421602

On Mon, Jun 13, 2016 at 5:52 AM, Kirill A. Shutemov
<kirill.shutemov@linux.intel.com> wrote:
> On Sat, Jun 11, 2016 at 06:02:57PM -0700, Linus Torvalds wrote:
>>
>> I've timed it at over a thousand cycles on at least some CPU's, but
>> that's still peanuts compared to a real page fault. It shouldn't be
>> *that* noticeable, ie no way it's a 6% regression on its own.
>
> Looks like setting accessed bit is the problem.

Ok. I've definitely seen it as an issue, but never to the point of
several percent on a real benchmark that wasn't explicitly testing
that cost.

I reported the excessive dirty/accessed bit cost to Intel back in the
P4 days, but it's apparently not been high enough for anybody to care.

> We spend 36% more time in page walk only, about 1% of total userspace time.
> Combining this with page walk footprint on caches, I guess we can get to
> this 3.5% score difference I see.
>
> I'm not sure if there's anything we can do to solve the issue without
> screwing relacim logic again. :(

I think we should say "screw the reclaim logic" for now, and revert
commit 5c0a85fad949 for now.

Considering how much trouble the accessed bit is on some other
architectures too, I wonder if we should strive to simply not care
about it, and always leaving it set. And then rely entirely on just
unmapping the pages and making the "we took a page fault after
unmapping" be the real activity tester.

So get rid of the "if the page is young, mark it old but leave it in
the page tables" logic entirely. When we unmap a page, it will always
either be in the swap cache or the page cache anyway, so faulting it
in again should be just a minor fault with no actual IO happening.

That might be less of an impact in the end - yes, the unmap and
re-fault is much more expensive, but it presumably happens to much
fewer pages.

What do you think?

             Linus

[toc] | [prev] | [next] | [standalone]

#1421660

On Mon, Jun 13, 2016 at 11:11:05PM -0700, Linus Torvalds wrote:
> On Mon, Jun 13, 2016 at 5:52 AM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
> > On Sat, Jun 11, 2016 at 06:02:57PM -0700, Linus Torvalds wrote:
> >>
> >> I've timed it at over a thousand cycles on at least some CPU's, but
> >> that's still peanuts compared to a real page fault. It shouldn't be
> >> *that* noticeable, ie no way it's a 6% regression on its own.
> >
> > Looks like setting accessed bit is the problem.
> 
> Ok. I've definitely seen it as an issue, but never to the point of
> several percent on a real benchmark that wasn't explicitly testing
> that cost.
> 
> I reported the excessive dirty/accessed bit cost to Intel back in the
> P4 days, but it's apparently not been high enough for anybody to care.
> 
> > We spend 36% more time in page walk only, about 1% of total userspace time.
> > Combining this with page walk footprint on caches, I guess we can get to
> > this 3.5% score difference I see.
> >
> > I'm not sure if there's anything we can do to solve the issue without
> > screwing relacim logic again. :(
> 
> I think we should say "screw the reclaim logic" for now, and revert
> commit 5c0a85fad949 for now.

Okay. I'll prepare the patch.

> Considering how much trouble the accessed bit is on some other
> architectures too, I wonder if we should strive to simply not care
> about it, and always leaving it set. And then rely entirely on just
> unmapping the pages and making the "we took a page fault after
> unmapping" be the real activity tester.
> 
> So get rid of the "if the page is young, mark it old but leave it in
> the page tables" logic entirely. When we unmap a page, it will always
> either be in the swap cache or the page cache anyway, so faulting it
> in again should be just a minor fault with no actual IO happening.
> 
> That might be less of an impact in the end - yes, the unmap and
> re-fault is much more expensive, but it presumably happens to much
> fewer pages.
> 
> What do you think?

Well, we cannot do this for anonymous memory. No swap -- no swap cache, if
I read code correctly.

I guess it's doable for file mappings. Although I would expect regressions
in other benchmarks. IIUC, it would require page unmapping to propogate
page to active list, which is suboptimal.

And implications for page_idle is not clear to me.

Rik, Mel, any comments?

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1422050

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-06-14 at 11:26 +0300, Kirill A. Shutemov wrote:
> On Mon, Jun 13, 2016 at 11:11:05PM -0700, Linus Torvalds wrote:
> > 
> > On Mon, Jun 13, 2016 at 5:52 AM, Kirill A. Shutemov
> > <kirill.shutemov@linux.intel.com> wrote:
> > > 
> > > On Sat, Jun 11, 2016 at 06:02:57PM -0700, Linus Torvalds wrote:
> > > > 
> > > > 
> > > > I've timed it at over a thousand cycles on at least some CPU's,
> > > > but
> > > > that's still peanuts compared to a real page fault. It
> > > > shouldn't be
> > > > *that* noticeable, ie no way it's a 6% regression on its own.
> > > Looks like setting accessed bit is the problem.
> > Ok. I've definitely seen it as an issue, but never to the point of
> > several percent on a real benchmark that wasn't explicitly testing
> > that cost.
> > 
> > I reported the excessive dirty/accessed bit cost to Intel back in
> > the
> > P4 days, but it's apparently not been high enough for anybody to
> > care.
> > 
> > > 
> > > We spend 36% more time in page walk only, about 1% of total
> > > userspace time.
> > > Combining this with page walk footprint on caches, I guess we can
> > > get to
> > > this 3.5% score difference I see.
> > > 
> > > I'm not sure if there's anything we can do to solve the issue
> > > without
> > > screwing relacim logic again. :(
> > I think we should say "screw the reclaim logic" for now, and revert
> > commit 5c0a85fad949 for now.
> Okay. I'll prepare the patch.
> 
> > 
> > Considering how much trouble the accessed bit is on some other
> > architectures too, I wonder if we should strive to simply not care
> > about it, and always leaving it set. And then rely entirely on just
> > unmapping the pages and making the "we took a page fault after
> > unmapping" be the real activity tester.
> > 
> > So get rid of the "if the page is young, mark it old but leave it
> > in
> > the page tables" logic entirely. When we unmap a page, it will
> > always
> > either be in the swap cache or the page cache anyway, so faulting
> > it
> > in again should be just a minor fault with no actual IO happening.
> > 
> > That might be less of an impact in the end - yes, the unmap and
> > re-fault is much more expensive, but it presumably happens to much
> > fewer pages.
> > 
> > What do you think?
> Well, we cannot do this for anonymous memory. No swap -- no swap
> cache, if
> I read code correctly.
> 
> I guess it's doable for file mappings. Although I would expect
> regressions
> in other benchmarks. IIUC, it would require page unmapping to
> propogate
> page to active list, which is suboptimal.
> 
> And implications for page_idle is not clear to me.
> 
> Rik, Mel, any comments?

We can clear the accessed/young bit when anon pages are moved
from the active to the inactive list.

Reclaim does not care about the young bit on active anon pages
at all. For anon pages it uses a two hand clock algorithm, with
only pages on the inactive list being cared about.

For file pages, I believe we do look at the young bit on mapped
pages when they reach the end of the inactive list. Again, we
only care about the young bit on inactive pages.

One option may be to count on actively used file pages actually
being on the active list, and always set the young bit on ptes
when the page is already active.

Then we can let reclaim do its thing with the smaller number of
pages that are on the inactive list, while doing the faster thing
for pages that are on the active list.

Does that make sense?

-- 
All Rights Reversed.

[toc] | [prev] | [next] | [standalone]

#1421918

On 06/14/2016 08:11 AM, Linus Torvalds wrote:
> On Mon, Jun 13, 2016 at 5:52 AM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
>> On Sat, Jun 11, 2016 at 06:02:57PM -0700, Linus Torvalds wrote:
>>>
>>> I've timed it at over a thousand cycles on at least some CPU's, but
>>> that's still peanuts compared to a real page fault. It shouldn't be
>>> *that* noticeable, ie no way it's a 6% regression on its own.
>>
>> Looks like setting accessed bit is the problem.
> 
> Ok. I've definitely seen it as an issue, but never to the point of
> several percent on a real benchmark that wasn't explicitly testing
> that cost.
> 
> I reported the excessive dirty/accessed bit cost to Intel back in the
> P4 days, but it's apparently not been high enough for anybody to care.
> 
>> We spend 36% more time in page walk only, about 1% of total userspace time.
>> Combining this with page walk footprint on caches, I guess we can get to
>> this 3.5% score difference I see.
>>
>> I'm not sure if there's anything we can do to solve the issue without
>> screwing relacim logic again. :(
> 
> I think we should say "screw the reclaim logic" for now, and revert
> commit 5c0a85fad949 for now.
> 
> Considering how much trouble the accessed bit is on some other
> architectures too, I wonder if we should strive to simply not care
> about it, and always leaving it set. And then rely entirely on just
> unmapping the pages and making the "we took a page fault after
> unmapping" be the real activity tester.
> 
> So get rid of the "if the page is young, mark it old but leave it in
> the page tables" logic entirely. When we unmap a page, it will always
> either be in the swap cache or the page cache anyway, so faulting it
> in again should be just a minor fault with no actual IO happening.
> 
> That might be less of an impact in the end - yes, the unmap and
> re-fault is much more expensive, but it presumably happens to much
> fewer pages.

FWIW, something like that is what Martin did for s390 3 years ago.
We now use invalidation and page faults to implement the *young 
functions in  pgtable.h (basically using a SW young bit). This
helped us to get rid of the storage keys (which contain the HW 
reference bit). The performance did not seem to suffer.

See commit 0944fe3f4a323f436180d39402cae7f9c46ead17
s390/mm: implement software referenced bits

> 
> What do you think?

Your proposal would be to do the software tracking via
invalidation/fault part of the generic mm code and not to hide it
in the architecture backend. Correct?

> 
>              Linus
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web