From owner-freebsd-questions Fri Aug 4 01:11:12 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id BAA27296 for questions-outgoing; Fri, 4 Aug 1995 01:11:12 -0700 Received: from diamond.sierra.net (diamond.sierra.net [204.94.39.235]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id BAA27289 for ; Fri, 4 Aug 1995 01:11:09 -0700 Received: from martis-d222.sierra.net by diamond.sierra.net with SMTP id AA25059 (5.67b8/IDA-1.5 for ); Fri, 4 Aug 1995 01:11:03 -0700 Message-Id: <199508040811.AA25059@diamond.sierra.net> From: "Jim Howard" To: dyson@root.com, freebsd-questions@freefall.cdrom.com Date: Fri, 4 Aug 1995 00:14:29 -0800 Subject: Re: 2.0.5 Eager to go into swap Reply-To: jiho@sierra.net X-Confirm-Reading-To: jiho@sierra.net X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail/Windows (v1.22) Sender: questions-owner@FreeBSD.org Precedence: bulk dyson@root.com says: > I suspect that part of the reason for the varied performance reports > has partially to do with disk performance among other things. > Paging performance depends very highly on your disk performance > and there is almost no way around that simple fact!!! One area in which FreeBSD has absolutely nothing to fear is performance. It runs circles around everything I've ever had on this machine, including DOS (although that by a lesser margin than the others). In fact, I was shocked when I discovered the paging that was going on with X, because I hadn't noticed it from the performance! The first performance problem caused by swapping was when I ran out of swap space, and a program got shut down on me! I actually considered the possibility that this was some kind of bogus reporting by swapinfo, some kind of "virtual paging" or something. It was hard to believe. Linux did a similar amount of paging and likewise ran out of swap space, but its disk access was so much slower that the thrashing was rather evident. I have a fairly fast SCSI drive (Micropolis 4110), but a ridiculously old SCSI adapter (Adaptec 1542B) that really gets in its way, and a 486DX/33 with 128 KB cache and 8 MB of DRAM, so we're not looking at high-end hardware. But I take issue with the (implied) notion that somehow if better hardware will patch things up, that means whatever the software is doing is alright. Frankly, I'm appalled at the unquestioning acceptance people express for X's in-core profile. Not everything is relative, you know. In any case, I seem to have stirred up so much dust here that I'm now very, very confused about where the line is between X and the FreeBSD kernel, in terms of responsibility for X sessions overrunning physical RAM. I don't know if it's your malloc() routine, or your shared library management, or something haywire in the way pages are allocated or recorded or reported, or just X and its clients requesting crazy amounts of memory. Enough wild statments have been tossed around that I know I won't rest until I've rummaged into the code in search of answers.... --Jim Howard