Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpfcso!dgr
From: dgr@hpfcso.HP.COM (Dave Roberts)
Newsgroups: comp.arch
Subject: Re: Is handling off-alignment important? (was Re: RISC hard to program?)
Message-ID: <8840016@hpfcso.HP.COM>
Date: 24 Jul 90 19:28:43 GMT
References: <104037@convex.convex.com>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 53


Bill writes:

> In article <8840014@hpfcso.HP.COM> dgr@hpfcso.HP.COM (Dave Roberts) writes:
> 
> | What if page 2 is paged out?  When does the CPU notice that it's paged
> | out and what does it do about it?  Does it abort the transaction
> | entirely, bring page 2 back in, and restart?  If so, what if, because
> | of the page replacement algorithm, page 1 gets blown away by bringing
> | in page 2?  
> 
>   You simply restart the instruction. Using an LRU scheme the 1st page
> would not get paged out unless the physical mapping was 1 page/process.
> As a reasonable constraint you want 8 pages/process anyway, so you avoid
> this.
> 
>   Note 1: yes "simply" is a relative term in this case, relative to doing
> half the instruction and then handling the fault.
> 
>   Note 2: pages for code, stack, source of copy instruction, dest of
> copy instruction. If you allow unalligned access you need two pages in
> each area to handle access over a boundary, that totals eight. No, I
> wouldn't want to actually run a system with that little memory.
> 
> -- 
> bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
>             "Stupidity, like virtue, is its own reward" -me
> ----------


Yea, I agree with you if LRU is the strategy, but how do you know what
page replacement strategy is being used?  This isn't usually something
that the hardware specifies.  It is usually (read always :-) left to
the O/S to implement.  The O/S could implement a FIFO strategy and
page 1 could have been the first page in.  I'm not disagreeing, just
raising some questions.

I understand that the problem can be solved and many of the techniques
for solving it.  What I'm interested in is: how much you pay for the
solution?  How much time is spent trying to solve it?  How much does
it cost in terms of overall performance?  How often is it used?  If
it's more expensive than doing aligned transactions even for
processors that support it, do users tend to try and make all their
transactions aligned?  If so, why have it and thereby slow down
everything?  Why not leave software to deal with the case when a user
has to do unaligned transactions?  Do users really want to pay the
price all the time for this support or would they rather take a big
hit every so soften?  Obviously some will and some won't but that's
the case for any architectural decision.  These are the questions I'm
really trying to answer.

Dave Roberts
dgr@hpfcla.fc.hp.com