Re: [Boost-bugs] [Boost C++ Libraries] #9019: Bug: mapped_region shouldn't create a new file mapping but reuse the one provided in file_mapping

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9019: Bug: mapped_region shouldn't create a new file mapping but reuse the one provided in file_mapping
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-08-20 21:55:41


#9019: Bug: mapped_region shouldn't create a new file mapping but reuse the one
provided in file_mapping
-------------------------+-------------------------------------------------
  Reporter: | Owner: igaztanaga
  michal.fronczyk@… | Status: new
      Type: Bugs | Component: interprocess
 Milestone: To Be | Severity: Optimization
  Determined | Keywords: interprocess mapped_region
   Version: Boost | file_mapping
  1.54.0 |
Resolution: |
-------------------------+-------------------------------------------------

Comment (by michal.fronczyk@…):

 Thanks for such a quick response. I think the problem is not about the
 time needed to create file mapping, but about the lack of ability to reuse
 already fetched pages of the file in different mapped regions. The
 performance problem we observed occurred in a multithreaded program. Using
 a profiler we discovered that the problem lies in the code where many
 threads were creating read-only mapped_regions of the same file using a
 shared instance of the file_mapping class. Different threads mapped
 different regions of the file, but there was a very high probability that
 a thread will shortly need the data region mapped previously by one of the
 other threads. I'm assuming that the destructor of the mapped_region class
 releases the mapping, so all the pages fetched during using that region
 are released when the region is destroyed and need to be fetched again
 from the disk when another region maps the same part of the file. Fetching
 the same parts of the file many times hurts the performance in our case.

 We changed the code to create one shared read-only mapped_region that maps
 the whole file and we use pointer arithmetic to read different parts of
 the file in different threads. The performance gain we observed was
 significant, but I don't have the numbers now. However, this solution
 isn't ideal because we can't do that in the 32bit version of the app since
 the file is big (several GBs). We map the whole file in the 64bit version
 only. BTW, do you see any problems with mapping a 20GB file as a whole to
 the 64bit address space?

 My thinking is that keeping the file_mapping instance and reusing it in
 multiple mapped_regions, that map small portions of the file, will allow
 us to reuse the fetched file pages in different mapped_regions as needed
 and the performance will be more or less the same as in the case of one
 shared mapped_region that maps the whole file. Please let me know if I'm
 wrong.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9019#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:13 UTC