Interesting presentation
|
Prev: Multi-core lag for Left 4 Dead 1 and 2 and Quake 4 on AMD X23800+ processor... why ?
Next: Which is the most beautiful and memorable hardware structure in a CPU?
From: Del Cecchi on 4 Apr 2010 22:31 <nmm1(a)cam.ac.uk> wrote in message news:hp81di$sso$1(a)smaug.linux.pwf.cam.ac.uk... > In article <4BB77FAE.5030203(a)patten-glew.net>, > Andy \"Krazy\" Glew <ag-news(a)patten-glew.net> wrote: >> >>> What I don't understand is why everybody is so attached to demand >>> paging - it was near-essential in the 1970s, because memory was >>> very limited, but this is 35 years later! As far as I know, NONE >>> of the facilities that demand paging provides can't be done >>> better, >>> and more simply, in other ways (given current constraints). >> >>I think my last post identified a slightly far-out reason: you can >>page >>without knowledge of software. But you can't swap. > > Hmm. Neither are entirely true - think of truly time-critical code. > I have code that will work together with swapping, but not paging. > >>Paging (and other oblivious caching) has a more graceful fall-off. >>Note >>that I can't say truly graceful, because modern OSes don't page >>well. > > Not in my experience, sorry. Even under MVS, which did, IBM learnt > that paging was a disaster area for far too many uses and backed off > to use swapping where at all possible. And "don't page well" often > translates to "hang up and crash in truly horrible ways, often > leaving > filesystems corrupted." > >>If you are doing whole program swapping, you can't run a program >>larger >>than memory With paging you can - although you better not be >>accessing a >>footprint larger than memory >> >>If you are doing segment swapping, and if data structures are >>constrained to be no larger than a segment, then you can't have a >>data >>structure larger than main memory. Or even approaching in size, >>since >>you will hae other segments. With paging you can. >> >>Sure, there have been compilers that automatically split up stuff >>like >>"char array[1024*1024*1024*16]" into multiple segments (where >>segments >>had a fixed maximum size). But that sure does look like paging. >>Just >>potentially with variable size pages. > > All of the above is true, in theory, but I haven't even heard of a > current example where those really matter, in practice - which isn't > due to a gross (software) misdesign. > > The point is that paging works (in practice) only when your access > is > very sparse (either in space or time) AND when the sparse access is > locally dense. I don't know of any uses where there are not much > better solutions. > >>Hmmm... modern techniques like COW zero filled pages and forking >>work >>better with pages than with segments. You could COW whole segments. >>But it really is better to have a level underneath the segments. It >>could be segments and sub-segments, but it so often is segments and >>paging. And if you have paging, you don't need segments. > > Why? That's a serious question? See above. In any case, the > fork-join > model is a thoroughgoing misdesign for almost all purposes, and most > COW uses are to kludge up its deficiencies. Please note that I was > NOT proposing a hardware-only solution! > >>Segments are associated far too often with restrictions such as "you >>can't have data structures bigger than 64K." Or 1G, Or 2^40 Such >>restrictions are the kiss of death. > > I am not talking about such misdesigns, but something competently > designed. After all, handling segments properly isn't exactly a new > technology. > > > > Regards, > Nick Maclaren. If you are expecting to be moving stuff back and forth to disk anyway, why not dust off the S/38 idea and use disk for main memory, with dram "main memory" as a cache? Works well with very large virtual addresses, like those of 64 bits. :-)
From: nmm1 on 5 Apr 2010 05:06 In article <81t0biF9ujU1(a)mid.individual.net>, Del Cecchi <delcecchi(a)gmail.com> wrote: > >If you are expecting to be moving stuff back and forth to disk anyway, >why not dust off the S/38 idea and use disk for main memory, with dram >"main memory" as a cache? Works well with very large virtual >addresses, like those of 64 bits. > >:-) Indeed, but the timings are such that we are moving in the opposite direction! Still, there are applications where that old approach is still the best one, but decreasingly many. What I am talking about is the converse, which is more appropriate for most uses. I.e. to shift the whole hierarchy the other way, simplifying as it is done. Regards, Nick Maclaren.
From: nmm1 on 5 Apr 2010 05:50 In article <do5n87-612.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <jwv4ojrjb4c.fsf-monnier+comp.arch(a)gnu.org>, >Stefan Monnier <monnier(a)iro.umontreal.ca> wrote: >>> The classic mainframe paging got underway when a disk access took somewhat >>> more than 200 instructions to perform. Now it is main memory that takes a >>> similar number of instructions to access. >> >>Are you saying that the classic mainframes switched from hardware-paging >>to software-paging more or less when disk accesses latency reached the >>"200 instructions" limit? >>I didn't know they used hardware paging before. > >The first pagers were very simple and primitive, like the ones >on the KI10, or the first IBM 370s. We would call it "hardware-assisted >software paging today". > >Real, full hardware paging came in the next generation of >machines. But the "hardware assisted" paging was still a huge >win. Yes. >>But in any case the situation nowadays is slightly different: we have >>a lot of cheap hardware real-estate, so we can afford to implement >>somewhat complex "paging" schemes in hardware, so I'd expect the >>threshold to be a good bit higher than 200 instructions. > >If we replace the cache-algorithms with "real" paging, where the >hardware does all the time-critical stuff, but software still has >control over the process I expect there to be substantial gains, but >there are no firm figures for this. I doubt it. The exact algorithms didin't help much with paging; the only real gains were by changing to using primarily swapping. >This could be a nice job for a handful of grad students somewhere >to build and evaluate. Build? That's a hell of an investment for a "handful of grad students". If caches were handled more competently, it would be easier (as well having great RAS and performance advantages). E.g. each thread/process would have cache limits (lower AND upper), which would be software controlled. That would go a long way to avoiding the design shambles by which unprivileged code can cause system failure by running very intermitted but time-critical privileged threads out of cache. And, as several of us have said before, TLBs are just caches for page tables, Regards, Nick Maclaren.
From: Anne & Lynn Wheeler on 5 Apr 2010 08:20 "Del Cecchi" <delcecchi(a)gmail.com> writes: > If you are expecting to be moving stuff back and forth to disk anyway, > why not dust off the S/38 idea and use disk for main memory, with dram > "main memory" as a cache? Works well with very large virtual > addresses, like those of 64 bits. folklore that s/38 deployed very early RAID because all disks were treated as common allocation pool with scatter allocation across disks. system required complete back up of all disks ... and then restore of all disks .... which could take a very long time ... for single disk failure ... or bad area on disk. one of the guys i worked with in sj disk engineering got patent on raid ... a decade before the term raid ... misc. past refs: http://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer" http://www.garlic.com/~lynn/2007t.html#72 Remembering the CDC 6600 http://www.garlic.com/~lynn/2009e.html#44 Architectural Diversity http://www.garlic.com/~lynn/2009s.html#33 Larrabee delayed: anyone know what's happening? there was tss/360 and multics that were memory mapped ... which FS adopted some features of ... and when FS was killed ... folklore was various people retreated to rochester to do s/38 http://www.garlic.com/~lynn/submain.html#futuresys i did memory mapped filesystem for cms (that was never released) ... drawing on some number of things that i saw tss/360 do wrong. http://www.garlic.com/~lynn/submain.html#mmap for other drift ... some details about FS http://www.jfsowa.com/computer/memo125.htm other pieces in this thread http://www.garlic.com/~lynn/2010g.html#42 Interesting presentation http://www.garlic.com/~lynn/2010g.html#43 Interesting presentation -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: nmm1 on 5 Apr 2010 09:34
In article <m37homum4g.fsf(a)garlic.com>, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: >"Del Cecchi" <delcecchi(a)gmail.com> writes: > >> If you are expecting to be moving stuff back and forth to disk anyway, >> why not dust off the S/38 idea and use disk for main memory, with dram >> "main memory" as a cache? Works well with very large virtual >> addresses, like those of 64 bits. > >folklore that s/38 deployed very early RAID because all disks were >treated as common allocation pool with scatter allocation across disks. > >system required complete back up of all disks ... and then restore of >all disks .... which could take a very long time ... for single disk >failure ... or bad area on disk. Well, yes. It's pretty obvious that you need different backup strategies for such systems to ones needed for 'conventional' use. >one of the guys i worked with in sj disk engineering got patent >on raid ... a decade before the term raid ... misc. past refs: And the idea was old then. Regards, Nick Maclaren. |