Date: Fri, 4 Aug 1995 00:14:29 -0800 From: "Jim Howard" <jiho@sierra.net> To: dyson@root.com, freebsd-questions@freefall.cdrom.com Subject: Re: 2.0.5 Eager to go into swap Message-ID: <199508040811.AA25059@diamond.sierra.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508040811.AA25059>