jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (11/24/90)
It's nearly on the air. I've managed to get the swap area increased (though
I wish the sa menus wouldn't replace /kernel/tower/cf/config.cf every time
they want to relink the OS...arrrgh), and have most of the software built.
There are a couple of things I'd like to change, though...namely the 1 meg
process maximum size and whatever the ulimit is set to. I'd ideally like to
remove both limits, or, failing that, at least st them to more reasonable
values (like 4 meg/process and a ulimit of at least 16 meg. Is this easy?
I've tried sticking a maxproc line in the config file, and the comment about
that being a Tower 32-specific feature in the config(1M) manpage is right:
while it changed a 0x100000 to a 0x400000 in /unix, the change had no effect,
at least as far as I could tell. The max process size reported at boot time
was 1 meg, and a dd if=/dev/rstp/0nn of=/tmp/foo bs=1024k complained about
running out of memory.
I haven't tried running into the ulimit yet explicitly, but it must be at
least 9 meg, since I've made a file that big...it doesn't appear to be
documented anywhere.
Thanks! I've gotten lots of help for this system, and all those who have
helped with sometimes dumb questions have made running cheap real Unix
possible for me.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity.
"With design like this, who needs bugs?" - Boyd Robertswescott@Columbia.NCR.COM (Mike Wescott) (11/26/90)
In article <4350@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: > I wish the sa menus wouldn't replace /kernel/tower/cf/config.cf every time Checkout the /sys directory. > There are a couple of things I'd like to change, though...namely the 1 meg > process maximum size and whatever the ulimit is set to. I'd ideally like to > remove both limits, or, failing that, at least st them to more reasonable > values (like 4 meg/process and a ulimit of at least 16 meg. Is this easy? Yes. Just upgrade to a Tower32. The ulimit is already set to some enormous value by default. The process size is limited by MMU restrictions. There is only 2Mb of address space that can be mapped by MMU, which must be shared by user programs and the kernel. Sorry, but you are stuck with 1Mb for user programs. > I haven't tried running into the ulimit yet explicitly, but it must be at > least 9 meg, since I've made a file that big...it doesn't appear to be > documented anywhere. Try the ulimit bourne shell built-in. It returns the ulimit in blocks. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (11/28/90)
In article <1990Nov26.145925.11125@nncrcae.Columbia.NCR.COM> wescott@Columbia.NCR.COM (Mike Wescott) writes: >In article <4350@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: >> I wish the sa menus wouldn't replace /kernel/tower/cf/config.cf every time >Checkout the /sys directory. Thanks for the pointer; that fixed that problem. >> There are a couple of things I'd like to change, though...namely the 1 meg >> process maximum size and whatever the ulimit is set to. I'd ideally like to >> remove both limits, or, failing that, at least st them to more reasonable >> values (like 4 meg/process and a ulimit of at least 16 meg. Is this easy? >Yes. Just upgrade to a Tower32. Perhaps I should have been a bit more specific: "Is this easy and cheap?" :-) >The ulimit is already set to some enormous value by default. The process >size is limited by MMU restrictions. There is only 2Mb of address space >that can be mapped by MMU, which must be shared by user programs and the >kernel. Sorry, but you are stuck with 1Mb for user programs. I noticed the ulimit(2) call shortly after I posted this, and found the enormous value that the limit is set to with a short C program. I'm glad NCR did something reasonable with this feature, as opposed to a lot of other System V vendors... I guess I'll have to watch out for the 1 meg per-process limit. At least there's a good technical reason for it. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "With design like this, who needs bugs?" - Boyd Roberts