Johnny Luo wrote: > A little suprising for me.With 31-bit addressing,if you have 10G real > storage,only 2G can be addressable as central storage.Then,how > about the use of other 8G real storage?Used as a substitiution for > paging data sets?
3033 had a gimick ... it was still 24bit virtual (and real) addressing (aka 16mbytes) ... however, it offered a 32mbyte real storage option. the (370) PTE was 16bits ... 12bits used for specifying a real page number (12bit/4k virtual pages ... or 4096 4096byte pages ... 16mbyte). two more bits were used for status ... and two bits were undefined. for the 32mbyte real storage option ... one of the undefined bits were used as an additional real page number ... allowing up to 8192 real 4k pages to be specified (or 32mbytes). each application had its own 16mbyte virtual address space ... however possibly 13mbytes of each virtual address space was common ... leaving ... effectively at most 3mbytes unique for application. lets say most of the mvs kernel (8mbytes) and most of a 5mbyte common segment was resident at a particular moment ... that would take up 13mbytes of real storage ... leaving possibly 19mbytes (out of 32mbyte real). you could have dozens of applications and subsystems running concurrently ... each with their own unique address space and unique pages. lets say there were 40 concurrent applications and subsystems that might be running at any point in time ... if they had the max. 3mbytes each ... that would account for 120mbytes of total unique virtual memory (spread across the 40 different virtual address spaces). whith possibly only 19mbytes left of available real storage ... only 19mbytes of the 120mbyte possible virtual pages could be resident in real storage at any point in time. real addressing couldn't address more than 16mbytes of real storage ... and virtual addressing couldn't address more than 16mbytes of virtual storage ... however there could be hundreds of megabytes of total virtual storage spread across scores of different virtual address spaces. the only additional thing required as being able to generate a real addresses for I/O larger than 16mbytes. That was provided with 31bit idal i/o addressing. In any case, even if the virtual (and/or real) instruction addressing can't directly address all of real storage ... it is still possible to fully utilize real storage that is much larger than the instruction addressing capability (using the ability of the virtual memory addresses to have hardware that can resolve/translate to a much larger real address ... along with the ability to have multiple concurrent virtual address spaces). So if you have 31bit virtual (instruction) addressing and much more than 2gbyte real storage ... all you need is for the virtual->real hardware addressing mechanism to handle maping to real page numbers that are greater than 2gbyte. each 2gbyte virtual address space can't address/occupy more than 2gbyte real storage ... however, with scores or hundreds of different 2gbyte virtual address spaces ... it is easily possible to have aggregate virtual pages well in excess of 10gbytes (not all of which could be real storage resident ... even with 10gbytes of real storage). note that the 3090 had a different issue with expanded storage feature. as noted in these related posts ... the physical packaging limited the amount of memory that could be within the 3090 instruction fetch latency specification. they went to a two-level software managed hiearchy called expanded storage. this had a longer latency, wider memory bus than was used for standard executable memory (allowing for being placed at greater distance). kernel software instructions was used to move 4k pages back and forth between regular memory and physical memory (in that sense it was sorted of treated as an electronic paging device ... but using synchronous instruction moves instead of asynchronous i/o). recent posts in a thread talking about partitioning current storage as emulated "3090" expanded storage: http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage http://www.garlic.com/~lynn/2006b.html#16 {SPAM?} Re: Expanded Storage http://www.garlic.com/~lynn/2006b.html#17 {SPAM?} Re: Expanded Storage http://www.garlic.com/~lynn/2006b.html#18 {SPAM?} Re: Expanded Storage past posts mentioning 3033 32mbyte support http://www.garlic.com/~lynn/2001m.html#15 departmental servers http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory? http://www.garlic.com/~lynn/2005.html#43 increasing addressable memory via paged memory? http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design http://www.garlic.com/~lynn/2005p.html#19 address space http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3 http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries? as mentioned in some of the above references ... one of the issues prompting 32mbyte feature on the 3033 was significant real storage requirements by mvs kernel and subsystems (not only was there significant pressure being placed on amount of virtual addressable storage by the mvs kernel and subsystem requirements ... but the same features were also consuming significant amounts of real storage causing enormous paging pressure). the other was that the endicott midrange 4341 was a real price/performance killer ... not only was it extremely competitive with other offerings (like dec vax) in its market segment ... but a cluster of six 4341s was about the same price as a 3033, had higher aggregate mip rate than 3033, could configured with an aggregate of 96mbytes (16mbytes for each 4341) and an aggregate of 36 i/o channels (6 i/o channels for each 4341). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
