Re: 2.6.9-rc1: page_referenced_one() CPU consumption

[Nikita Danilov <nikita@clusterfs.com>]

Nick Piggin writes:
 > Hugh Dickins wrote:
 > > On Fri, 10 Sep 2004, Hugh Dickins wrote:
 > > 
 > >>I'm quite content to go back to a trylock in page_referenced_one - and
 > >>in try_to_unmap_one?  But yours is the first report of an issue there,
 > >>so I'm inclined to wait for more reports (which should come flooding in
 > >>now you mention it!), and input from those with a better grasp than I
 > >>of how vmscan pans out in practice (Andrew, Nick, Con spring to mind).
 > > 
 > > 
 > > Just want to add, that there'd be little point in changing that back
 > > to a trylock, if vmscan ends up cycling hopelessly around a larger
 > > loop - though if the larger loop is more preemptible, that's a plus.
 > > 
 > 
 > Yeah - I'm not sure why a trylock would perform better. If it is just
 > one big address space, and memory needs to be freed, presumably the
 > scanner will just choose a different page, and try the lock again.
 > 
 > Feel like doing a few more quick tests Nikita? ;)

Ok, here are my highly unscientific results.

Work-load: copying 1G _byte_ file from XNU lustre client to the UML
lustre server running in the 2.6.9-rc1 host.

Top CPU consumers according to readprofile:

2.6.9-rc1 vanilla:

  3312 prio_tree_parent                          41.4000
  3483 ide_do_request                             3.9806
  4899 page_referenced_file                      25.1231
  6138 __copy_from_user_ll                       78.6923
  7461 get_offset_pmtmr                          54.0652
  7492 __copy_to_user_ll                         96.0513
  8042 finish_task_switch                        76.5905
  9657 prio_tree_next                            76.0394
 10083 wait_task_stopped                         11.7517
 11080 sigprocmask                               53.0144
 13345 prio_tree_right                           65.4167
 14956 vma_prio_tree_next                       173.9070
 15838 prio_tree_left                            92.6199
 27049 eligible_child                           124.0780
 28533 try_to_unmap_one                          64.8477
 33810 system_call                              768.4091
 49865 __preempt_spin_lock                      547.9670
 56045 do_wait                                   47.5360
109964 page_referenced_one                      388.5654
1529155 mwait_idle                               19604.5513
2011318 total                                      0.7514

2.6.9-rc1 with patch (below) applied:

  2999 prio_tree_parent                          37.4875
  3012 ide_outbsync                             301.2000
  3272 ide_do_request                             3.7394
  4365 page_referenced_file                      22.3846
  6031 __copy_to_user_ll                         77.3205
  6296 __copy_from_user_ll                       80.7179
  7563 get_offset_pmtmr                          54.8043
  7698 finish_task_switch                        73.3143
  9133 prio_tree_next                            71.9134
  9817 wait_task_stopped                         11.4417
 13242 prio_tree_right                           64.9118
 13620 vma_prio_tree_next                       158.3721
 15736 prio_tree_left                            92.0234
 17768 sigprocmask                               85.0144
 26260 try_to_unmap_one                          59.9543
 27096 eligible_child                           124.2936
 28141 system_call                              639.5682
 41002 __preempt_spin_lock                      450.5714
 58325 do_wait                                   49.4699
101512 page_referenced_one                      347.6438
1648567 mwait_idle                               21135.4744
2107521 total                                      0.7874

Patch:
----------------------------------------------------------------------
===== mm/rmap.c 1.77 vs edited =====
--- 1.77/mm/rmap.c      2004-08-24 13:08:39 +04:00
+++ edited/mm/rmap.c    2004-09-12 19:05:26 +04:00
@@ -268,7 +268,8 @@
        if (address == -EFAULT)
                goto out;
 
-       spin_lock(&mm->page_table_lock);
+       if (!spin_trylock(&mm->page_table_lock))
+               goto out;
 
        pgd = pgd_offset(mm, address);
        if (!pgd_present(*pgd))
----------------------------------------------------------------------

I ran tests few times, and difference between patched and un-patched
kernels is within noise, so you are right, try-lock does not help.

But now I have new great idea instead. :)

I think page_referenced() should transfer dirtiness to the struct page
as it scans pte's. Basically the earlier we mark page dirty the better
file system write-back performs, because page has more chances to be
bulk-written by ->writepages(). This is better than my previous patches
to this end (that used separate function to transfer dirtiness from
pte's to the page), because

    - locking overhead is avoided

    - it's simpler.

Nick, are you still in business of benchmarking random VM patches? :-)

Nikita.