The default size of the mapped memory for a stream is driven by a #define in a header file so it isn't hard to change it. I believe an application can also use sfsetbuf(f, NULL, size) to set a desired size for the mapped buffer.
Generally speaking, Sfio and our other core libraries like CDT and Vmalloc have been around for a very long time and their default parameters tend to stay as they are until someone notices a performance issue. Well, not so much for Vmalloc anymore because it has been completely rewritten recently to deal with concurrency, both multiple threads and multiple processes for shared memory. Anyway, it is good that you bring up this issue with Sfio now. What do people think is a reasonable size to set the default mapped size to on a 64-bit machine? Keep in mind that there apps with many dozens files opened at the same time along with other large requirements for memory. Phong > From [email protected] Sun Apr 14 21:07:56 2013 > To: [email protected] > Subject: [ast-developers] mmap() for command substitutions still not living > up to its fullest potential? > Based on the recent discussion about using mmap() for reading the > results of command substitutions I did some testing and found that on > Solaris (Solaris 11 and a 64bit build) ksh93 still behaves not > optimal. The primary problem I see is that MANY mmap() calls with a > very small map size (524288 bytes) are executed instead of either > mapping the input file in one large chunk or at least uses a chunk > size large enough that the system can use largepages (2M for x86, > 4M/32M/256M for SPARC64) if possible. Using a chunk size of 524288 > bytes is a joke. > Is there a specific reason why the the code in sfrd.c only maps such > small chunks (I'd expect that a 64bit process could easily map 16GB > each time) from a file or is this a bug? _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
