kgallagh@digi.lonestar.org (Kevin Gallagher) (02/20/91)
We ran into a thread size limit running DSEE on our SR10.2 nodes. When we ran the same job on an SR10.3 node, we had no limit problem. The SR10.3 release notes, page 4-26, lists the following APR as closed since the release of SR10.2: 000DCE76 dsee DSEE length limit in model threads When we contacted HP/Apollo, their answer indicated that the above APR was fixed by DSEE 4.0 (we are using an older version on ALL our nodes). In DSEE 4.0, model thread sizes are no longer limited within DSEE itself, but only by factors like disk space, etc. So, "Why did SR10.3 fix it?" HP/Apollo's answer is that the model thread size limit is associated with a system "constant" SEG_SIZE in SR10.2. In SR10.3 this constant was changed to a function (?). In SR10.2, the limit is 32k. Information on the new limit for the "function" SEG_SIZE in SR10.3 was unknown by our contact. Does anyone know what the new limit is under SR10.3? Is this now configurable under SR10.3, since it is a "function" and no longer a "constant"? If so, how can we increase it? -- ---------------------------------------------------------------------------- Kevin Gallagher kgallagh@digi.lonestar.org OR ...!uunet!digi!kgallagh DSC Communications Corporation Addr: MS 152, 1000 Coit Rd, Plano, TX 75075 ----------------------------------------------------------------------------
rees@pisa.ifs.umich.edu (Jim Rees) (02/21/91)
In article <1991Feb20.153655.6540@digi.lonestar.org>, kgallagh@digi.lonestar.org (Kevin Gallagher) writes:
So, "Why did SR10.3 fix it?" HP/Apollo's answer is that the model
thread size limit is associated with a system "constant" SEG_SIZE
in SR10.2. In SR10.3 this constant was changed to a function (?).
In SR10.2, the limit is 32k. Information on the new limit for the
"function" SEG_SIZE in SR10.3 was unknown by our contact.
The function seg_size() returns the virtual memory segment size. The
sr10.2 version just returned a constant 32k:
32173C0: LINK.W A6,#FFFC
32173C4: MOVE.L #8000,D0
32173CA: MOVEA.L D0,A0
32173CC: UNLK A6
32173CE: RTS /
The sr10.3 version gets the value out of PM private data, where it was
presumably stored at node boot time. If you're using a newer node that has
an MMU that supports the new segment size (dn2500?), then switching to
sr10.3 will give a larger return value from seg_size().
If you're a cowboy you might be able to patch the place in dsee where it
calls seg_size(). This may void your warranty. I do not recommend trying
to patch the constant in the pmlib.