On 2012-12-19 17:38, Paul_Koning at Dell.com wrote:
On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote:
On 2012-12-19 03:27, Clem Cole wrote:
The page size on the VAX is 512 bytes and it lacked COW (copy-on-write)
HW (long, long story as to why, which I will not try to repeat). In
the end, this would be a huge problem with all VAX OSses and HW - take
look any of the sources.
[...]
Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.
However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit.
This is what we do in NetBSD/vax.
I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way.
Well, I was talking about implementing the MODIFY bit here, but yes, copy-on-write is an extension to this. However, I pretty much am sure that you cannot do it any easier to cheaper with copy-on-write. The MODIFY bit, though, is something most MMUs have in hardware - not so for the VAX. :-(
That becomes important when you want to know if a page is dirty or not...
Johnny
On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote:
On 2012-12-19 03:27, Clem Cole wrote:
The page size on the VAX is 512 bytes and it lacked COW (copy-on-write)
HW (long, long story as to why, which I will not try to repeat). In
the end, this would be a huge problem with all VAX OSses and HW - take
look any of the sources.
[...]
Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.
However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit.
This is what we do in NetBSD/vax.
I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way.
paul
"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes:
"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes:
sampsa at mac.com writes: > >>Is there some switch I can use to make
MONITOR CLUSTER use a larger >>screen than 80x24? > >I looked in the
HELP commands but found nothing >related. > >??? > >I routinely have 132
column SHOW CLUSTER display. I have a number of >ADD commands in my
SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER >to use the full 132
columns of my display. What is the width of your >terminal? (ie. $
WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns >what?)
Sorry, too early in the morn... MONITOR, not SHOW, CLUSTER.
OK. I just checked the sources for MONITOR and this is fixed. Here's
a comment from CLUFAO:
; The cluster screen in divided up into quadrants by a horizontal and verticle
; line. The quadrants are all equal in size (10 rows x 39 columns). The upper
; left quadrant displays the top 6 nodes CPU_BUSY statistic. The Upper right
; quadrant displays the top 6 MEMORY_UTILIZATION statistic. The lower left
; quadrant displays the top 6 disks total I/O rate statistic. And the lower
; left quadrant is up for grabs at this point.
Following this comment, there's a table which contains cursor positioning
values. All would maintain output that is strictly 80 column. If you're
looking for a 132 column variant, it looks like you'll have to write this
yourself. It should be pretty simple to do.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes:
sampsa at mac.com writes:
Is there some switch I can use to make MONITOR CLUSTER use a larger
screen than 80x24? > >I looked in the HELP commands but found nothing
related.
???
I routinely have 132 column SHOW CLUSTER display. I have a number of
ADD commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER
to use the full 132 columns of my display. What is the width of your
terminal? (ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns
what?)
Sorry, too early in the morn... MONITOR, not SHOW, CLUSTER.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
sampsa at mac.com writes:
Is there some switch I can use to make MONITOR CLUSTER use a larger
screen than 80x24?
I looked in the HELP commands but found nothing related.
???
I routinely have 132 column SHOW CLUSTER display. I have a number of ADD
commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER to use
the full 132 columns of my display. What is the width of your terminal?
(ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns what?)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Correct. Not having it is expensive, and adds difficulties to the SW. This is why wnj created/implemented vfork(2) for 4.1. While most codes could just s/fork/vfork/ careful reading needed to occur and some rewriting needed to happen. The HW guys finally relented.
On Wed, Dec 19, 2012 at 7:08 AM, Johnny Billquist <bqt at softjar.se> wrote:
Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.
On 2012-12-19 03:27, Clem Cole wrote:
The page size on the VAX is 512 bytes and it lacked COW (copy-on-write)
HW (long, long story as to why, which I will not try to repeat). In
the end, this would be a huge problem with all VAX OSses and HW - take
look any of the sources.
[...]
Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.
However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit.
This is what we do in NetBSD/vax.
I don't know of any architecture that has any kind of copy-on-write semantics in the MMU. I think that is way to complex to actually be possible in the MMU itself. OSes normally do copy-on-write by having the page read-only, and when a write happens, the page gets cloned, and then you have your own private copy, to which you can write.
But that implies allocating a new page, copy the contents of the old page over, and change the current page table. If you know of an MMU that can do that, I'm interested in hearing about it.
Johnny
On Wed, Dec 19, 2012 at 1:10 AM, Cory Smelosky <b4 at gewt.net> wrote:
Feel free to disregard, I was just playing with SPF records and I migrated away from gmail and wanted to make sure emails still get places properly.
Had to make sure, always a chance I broke something. ;)
Also: I will very soon have time to get back to making area 9 work.
Hello!
Disregard what? It works. Good for you.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
Feel free to disregard, I was just playing with SPF records and I migrated away from gmail and wanted to make sure emails still get places properly.
Had to make sure, always a chance I broke something. ;)
Also: I will very soon have time to get back to making area 9 work.
