Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter From: peter@ficc.ferranti.com (peter da silva) Newsgroups: comp.arch Subject: Re: Translating 64-bit addresses Message-ID: <92-9BOB@xds13.ferranti.com> Date: 10 Mar 91 17:50:11 GMT References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> Organization: Ferranti International Controls Corporation Lines: 67 In article , pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) writes: > peter> I don't think you can really make a good case [that sending segments back and forth gives much the same bandwidth] > Tell that to the people that ported Mach, and 4.3BSD to the PC/RT... :-) Hasn't the PC/RT been found to have surprisingly poor performance once the number of context switches involved get too high? > My estimate is that remapping can be done on demand (lazy remapping), > not on every context switch, and it does not cost more than a page fault > (which is admittedly an extremely expensive operation, Exactly. > but one about which people don't complain). Well, you and I have both complained about excessive paging in the past. > peter> Consider the 80286, where pretty much all memory access for large > peter> programs is done by remapping segments. > Are you sure? I think that in all OSes that run on the 286 maybe except > for iRMX/286 segments are not unmapped and remapped, but stay always > mapped, and can be and are shared. Once you want to access more than 256K (64K for each of DS, SS, CS, and ES) you *have* to reload the segment registers. The machine can *not* directly address more than 64K per segment, and it only has the 4 segment registers. This is a hard limit unless you start reloading segment registers... which is sufficiently expensive to have an exquisitely painful impact on performance. > peter> Loading a segment register is an expensive operation, > Around 20-30 cycles if memory serves me right. Compared to a context > switch it is insignificant. But it happens so much more often. > This said, your comments about the 286 MMU are irrelevant to a > discussion on acceptability of the cost of simulating shared memory by > remapping them on demand or at a context switch in each process that has > them nominally attached. Well, only that in the case you're talking about the cost of remapping the segments is even higher. [ re: costs of segment reloads on the 80286 ] > This is only because probably the HUGE model gets used, which implies > funny code to simulate 32 bit address arithmetic No, just large model. Once you have to operate on more than two data segments at a time (which basically means more than two objects at a time) you have to reload the segment register on each data access. > peter> I think it's clear from this experience that frequent reloading > peter> of segment registers is a bad idea. > No, the conclusion is not supported by the 286 example; the 286 is > uniquely poor for reloading segment registers because it does not treat > shadow segment registers as a cache and because its pointers have an > unfortunate format. True. Your point. Of course page faults are such a cheap operation. :-> -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"