Recently, Gioh worked to support non-LRU page migration[1].
zRAM is one of customer to use that feature.

For working with that, drivers have to register own address_space
via page->mapping and mark the page->_mapcount as MOBILE page.

Unfortunately, zram have been used those fields to keep own
metadata so there is no room in struct page, which makes hard
to work with the feature.

This patchset try to diet so the goal is to make page->mapping
and page->_mapcount empty.

Trade-off is CPU vs MEMORY so this patchset would make it slow
a bit. I did fio test with perf in my x86 mahchine.

before:

 Performance counter stats for './zram_fio.sh' (6 runs):

      11186.216003      task-clock (msec)         #    1.836 CPUs utilized      
    
             1,059      context-switches          #    0.098 K/sec              
    
               299      cpu-migrations            #    0.028 K/sec              
    
           159,221      page-faults               #    0.015 M/sec              
    
    17,629,290,725      cycles                    #    1.627 GHz                
      (83.56%)
    12,375,796,782      stalled-cycles-frontend   #   69.95% frontend cycles 
idle     (83.34%)
     8,566,377,800      stalled-cycles-backend    #   48.42% backend  cycles 
idle     (66.91%)
    12,828,697,359      instructions              #    0.73  insns per cycle    
    
                                                  #    0.96  stalled cycles per 
insn  (83.55%)
     2,099,817,436      branches                  #  193.734 M/sec              
      (83.66%)
        20,327,794      branch-misses             #    0.96% of all branches    
      (83.89%)

       6.092967906 seconds time elapsed                                         
 ( +-  1.49% )

new:

 Performance counter stats for './zram_fio.sh' (6 runs):

      10574.201402      task-clock (msec)         #    1.724 CPUs utilized      
    
             1,157      context-switches          #    0.107 K/sec              
    
               319      cpu-migrations            #    0.030 K/sec              
    
           159,196      page-faults               #    0.015 M/sec              
    
    17,825,134,600      cycles                    #    1.652 GHz                
      (83.61%)
    12,462,671,915      stalled-cycles-frontend   #   69.98% frontend cycles 
idle     (83.18%)
     8,699,972,776      stalled-cycles-backend    #   48.85% backend  cycles 
idle     (66.81%)
    12,958,165,862      instructions              #    0.73  insns per cycle    
    
                                                  #    0.96  stalled cycles per 
insn  (83.55%)
     2,135,158,432      branches                  #  197.936 M/sec              
      (83.80%)
        20,226,663      branch-misses             #    0.95% of all branches    
      (83.93%)

       6.133316214 seconds time elapsed                                         
 ( +-  1.80% )

There is a regression under about 1~2% so I think it's reasonable trade-off.

Notice: I marked it as RFC due to two things.

1. I didn't check ./script/checkpatch
2. If Gioh's work is dropped, there is no point to merge this patchset.

If there is no big problem found during review process and Gioh respins
new revision, I will implement migration functions based (this patchset +
Gioh's new).

Thanks.

[1] http://lwn.net/Articles/650917/

Minchan Kim (4):
  zsmalloc: keep max_object in size_class
  zsmalloc: squeeze inuse into page->mapping
  zsmalloc: squeeze freelist into page->mapping
  zsmalloc: move struct zs_meta from mapping to somewhere

 mm/zsmalloc.c | 346 +++++++++++++++++++++++++++++++++-------------------------
 1 file changed, 197 insertions(+), 149 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to