On Tue, 1 Jul 2008, Miles Nordin wrote: > > But, just read the assumptions. They're not really assumptions. > They're just definitions of what is RAM, and what is a time-sharing > system. They're givens.
In today's systems with two or three levels of cache in front of "RAM", variable page sizes, and huge complexities these are definitely not "givens". > A ``well-designed'' or ``second-to-none'' VM subsystem combined with > convenient programs that only use sequentially-accessed chunks of > memory does not avoid thrashing if the working set is larger than > physical RAM. This simplistic view was perhaps more appropriate 10 or 15 years ago than it is now when typical systems come with with 2GB or more RAM and small rack-mount systems can be fitted with 128GB of RAM. The notion of "chewing" before moving on is interesting but it is worthwhile noting that it takes some time for applications to "chew" through 2GB or more RAM so the simplistic view of "working set" is now pretty dated. The "chew and move on" you describe becomes the normal case for sequential access. Regardless, it seems that Solaris should be willing to supply a large virtual address space if the application needs it and the administrator should have the ability to apply limits. Dynamic reservation would decrease administrative overhead and would allow large programs to be run without requiring a permanent allocation. This would be good for me since then I don't have to permanently assign 32GB of space for swap in case I need it. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
