Well, it all depends on what you want to do, the requirements you have and how much money you have <G>.
For a particular application, cache is always better closer to the application then farther away. i.e. you create an array within your program and load the data there, and you can access it much faster then on any disk. But, you waste memory when the application isn't in use. Real memory costs real money (and if the memory is paged out, the speed of accessing the array is greatly dimished). In Linux, it will use any unused memory for cache. That cache can be used for any/all programs that is being used. Sounds great. And that is great on a dedicated platform. After all, on a dedicated platform, there is no other use for the memory. But, since we are talking about MDC which means VM, it usually isn't a dedicated platform. If you are running low on memory and can't afford the next bumb in memory (yet), you tune back the z/Linux caching, and let MDC handle more of the load. MDC is a shared cache, that is shared across all dasd where it isn't explicitly turned off. If one Linux image becomes very active, it will load MDC with it's data. But when the image becomes more idle, the cache will be used for more active images. More bang for the GB. Yep, not as good as dedicated cache within a z/Linux image, but still can ramp up good. But then you have to consider how fast your Disk Subsystem is. I thought it was fast with MP3000 Internal dasd, after all, no channels. But now we have a DS6800 Ficon-2 attached. I can do a CMS format of a 3390-3 in under 2 minutes. It use to take 20 minutes on the MP3000 and 45 minutes on escon attached Ramacs. Perhaps I don't need cache anymore<G>. Well, of course I do. But I can easily justify a lower cache hit rate and still have great response from my applications. The performance docs on the Shark said that a properly configured Shark can substain 30,000 I/Os per second. The number on the DS6800 state 300,000 I/Os per seconds. I take that with a grain of salt as I have configured the unit for our needs, not outright performance. But even if I only got 25% of the performance, that is still 75,000 I/Os per seconds. NOBODY NEEDS DATA THAT FAST! (just kidding) At some point, eventually, we might make the DS6800 work, not very hard, at providing our data needs. Cache, whether MDC, Linux cache, Oracle SGA, all eliminate the need for real I/O at a cost of real memory. Perhaps you have an Oracle database, that needs great response time. That might be a larger SGA (use up most of the available memory for cache, here) and the hell with all other work loads. Perhaps you needs everyone, most every one to get acceptable response. Then MDC may be the way. Perhaps turning off MDC for your test systems. (I usually don't do that as I consider programers to me be just another department of "users" that we need to keep productive.) IMHO, the hidden question in your question is... Do we need to rethink the use of MDC? And the answer normally is... Of course! As hardware/software and applications change, we should, always, eventually, take the time to rethink the proper usage of our resources. But then, who gets paid for that? <G>. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 09/05/05 3:01 AM >>> Johnny Tan wrote: > By default, z/VM minidisk cache is enable. As I know, z/VM minidisk cache is using z/VM real memory and expanded storage. Would anyone recommend to use minidisk cache on z/VM where the main purpose of z/VM here is to support Linux guests? > > Today's DASD technology has fast write, which means that writing to DASD will no longer write direct to the disk, however, it will write direct to the cache (which is memory) of the DASD controller. In view of this fast write feature, is minidisk cache still relevant? If it is still relevant, does the z/VM minidisk cache work well to predict open system I/O characteristics in view that I/O pattern of open system is random (not sequential) as compared to MVS ?? Given that Linux has good disk caching built-in, mdc does only make sense for shared volumes. Deactivating mdc for those volumes that are local to either of your guests saves double caching. -- Carsten Otte IBM Linux technology center ARCH=s390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
