Path: utzoo!attcan!uunet!seismo!dimacs.rutgers.edu!mips!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!husc6!encore!zelig!jdarcy From: jdarcy@encore.com (Jeff d'Arcy) Newsgroups: comp.sys.encore Subject: Re: Umax 4.3 virtual memory problem Keywords: Umax, paging, cow, bug Message-ID: Date: 18 Sep 90 11:33:27 GMT References: <1479@sirius.ucs.adelaide.edu.au> Sender: news@Encore.COM Lines: 56 gordoni@chook.adelaide.edu.au (Gordon Irlam) writes: > "How to sell overpriced memory expansion boards." I'm sure we could think of better ways to waste VM memory than what you mention. Maybe I'll submit a proposal. :-) >The program shown above was an extreme example of the problems that >non-pageable copy on write memory can cause, however all programs that >fork will cause problems to a certain extent. This prevents Umax from >being able to run processes whose total virtual memory size >significantly exceeds the amount of physical memory available, even >though such processes may be idle most of the time. This is true ONLY for programs that exhibit the type of behaviour you describe. As you've already pointed out, such behaviour is relatively rare and programs exhibiting it could well be considered misbehaved. This does *not* mean that they should be able to use up physical memory, but merely that the UMAX 4.3 kernel is not doing this all by itself. >We reported this bug to Encore around the end of April, so hopefully >they are aware of the problem and are working on a solution. We have >not yet received a reply from Encore. . . .so you posted this. We appreciate being made aware of the problem (as if we weren't already), but I'm sure you can appreciate that we'd prefer a different methodology from what you suggest. As for your not receiving a reply, all I can say is that I'm not in customer service so I won't attempt to speak for them. >it would be useful >if Encore posted to the net details of serious bugs when they are >first discovered, and made a more complete list of bugs available for >anonymous ftp. Yes, useful to our users, and even more useful to our competitors. The fact is that any system as complex as an SMP UNIX kernel is going to have bugs, and some of those are going to be pretty scary. Advertising our bugs while our higher-market-share competitors don't reciprocate gives them an unparalleled opportunity to slime us. As I'm sure you're aware, some of our competitors *already* make plenty of misleading claims about the relative merits of our machines vs. theirs, and this would be a godsend for their marketing/sales departments. Obviously I can't comment on the availability of future releases, and I honestly don't know the status of this *particular* problem. What I can say is that we have been aware of UMAX 4.3 VM problems for some time (we use it in-house too) and have no reason except resources to avoid fixing them. That's not *any* sort of a commitment; remember that I speak only for myself and not for Encore even in this group. Also, my mention of VM problems in UMAX 4.3 should not alarm anyone. These things are a fact of life, and I'll bet that at least one if not all of Dynix, IRIX and OSx have worse problems lurking somewhere. -- Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com Nothing was ever achieved by accepting reality