On Wed, 2011-12-14 at 16:27 -0500, Richard Troth wrote: > I suggest two things: > First, draw a line (this would be a somewhat arbitrary number). If > the disk is less than (for example) 256M (roughly 350 cyls of 3390), > then continue to use mmap/memcpy. If larger, then switch to > pread/pwrite. Second, provide a mount option so that the user can > always specify which model to they want. (With the option to be > explicit, there is little reason any of us can complain about where > you draw that line.)
I like that idea of using both methods, but I don't like the artificial limit. What I would like to do is the following: 1. mmap the disk (as before) 2. check for the -ENOMEM case 2a. mmap was successful -> go on use memcpy in the read/write functions 2b. mmap failed -> use pread/pwrite in the read/write functions That way we can avoid any memory setting changes since pread/pwrite will also work with very little memory. If the sysadmin sets ulimit -v cmsfs-fuse will also work. And in case there is enough memory it can be used to cache the disk operations. Is anybody ok with that approach or do you still see the need for an additional switch??? Jan > -- R; <>< > Rick Troth > Velocity Software > http://www.velocitysoftware.com/ > > > > > > On Wed, Dec 14, 2011 at 07:20, Jan Glauber <j...@linux.vnet.ibm.com> wrote: > > On Fri, 2011-12-02 at 14:05 -0600, David Boyes wrote: > >> > It's just mmap'ing the whole disk into the process's address space for > >> > the > >> > programmers sake. > >> > >> BAD idea (in the sense of 'broken as designed'). You're taxing the virtual > >> memory system in a shared-resource environment, which hurts the entire > >> environment for a little convenience in programming. > >> > >> > If that turns out to be a problem we could theoretically go back to > >> > pread/pwrite. But I'm not sure how many users have such large CMS disks? > >> > >> Please do. Doesn't matter if it's an edge case, it shouldn't do this. > > > > Since there seems to be collective disapproval of the requirement to > > touch the memory settings for large disks I'm looking into changing > > that... > > > > I can easily replace the mmap-memcpy with pread/pwrite. Unfortunately I > > see huge performance drops if I do so. Currently I'm looking why the > > system call variant costs so much more than mmap. > > > > Jan > > > >> ---------------------------------------------------------------------- > >> For LINUX-390 subscribe / signoff / archive access instructions, > >> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > >> visit > >> http://www.marist.edu/htbin/wlvindex?LINUX-390 > >> ---------------------------------------------------------------------- > >> For more information on Linux on System z, visit > >> http://wiki.linuxvm.org/ > >> > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
