On 21/02/13 05:42, Bret Busby wrote: > I have a desktop computer with an Intel I3 CPU, and 8GB of RAM, and, > it simply does not use the swap space (I had allocated 40GB) on the > hard drive.
You probably already tried it, but the setting of Linux sysctl vm.swappiness controls the balance of RAM/swap used, on some 0 to 100 scale. Also - just to make sure there was no misunderstanding - the output of the "free" command might suggest most of your RAM is "used", but: > $ free > total used free shared buffers cached > Mem: 8197112 7735536 461576 0 232124 4324500 > -/+ buffers/cache: 3178912 5018200 > Swap: 270332 223600 46732 The "- buffers" figure in the "used" column is the more accurate figure of RAM being used by userland software. Most of my RAM here is being used to cache disk I/O - and that is something it makes no sense to swap out to disk. As such, the only time this system ever touches swap is if I really do exhaust my available RAM with something. Or maybe sooner if I increased vm.swappiness all the way to 100. Any kind of swapping though hits this (Linux 3.2) system pretty hard - like you described - but after a minute or so it usually recovers. I agree that's bad. This is the sort of thing I imagine kFreeBSD might handle better. > It reminded me of the scenario with the Intel 80486 CPU, which, from > memory, introduced virtual machines, or, some other new extension [...] that > MS Windows 486 could not > properly use the capabilities of the 80486 CPU; Maybe something to do with the https://en.wikipedia.org/wiki/640_KB_barrier and its implications for virtual memory. Curiously enough, modern i386 systems in PAE mode have run into a similar problem, when trying to use 10's of GB of RAM. (Debian bug #695182 reported on Linux) The amd64 architecture avoids all of this though. > At that time, or, developing from that time, was the principle that > the primary (other problem) with MS Windows 486, was that it would run > for no more than 29 (I think it was) days, then it would automatically > crash, and require rebooting. >From https://en.wikipedia.org/wiki/Windows_98_SE : "A memory overflow issue was resolved which in the older version of Windows 98 would crash most systems if left running for 49.7 days (equal to 2³² milliseconds)." Coincidentally there was a bug in some Linux 2.6 timer code on i386 that could crash it at after 208 days (2^54 nanoseconds): https://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=patch;h=4cecf6d401a01d054afc1e5f605bcbfe553cb9b9 Also there was that leap second bug recently, where thousands of Linux machines in datacentres around the world jumped to 100% CPU load at the same moment. > I have also noticed that, on this system, when the RAM usage shows as > having reached about 60%, the system slows, especially dta > transmission through the ethernet card. For a driver or possibly hardware-related issue like this I do recommend at least trying GNU/kFreeBSD with the version 9 and/or 8 kernels, since the driver implementation will be different to Linux. It may work better, or otherwise you may be able to determine if it is in fact a hardware problem. > I had installed PC-BSD 9.0 (which is based on FreeBSD > 9.0) on an HP/Compaq NX5000 (Intel Celeron CPU, 2GB RAM), in a > multiple boot scenario I think on GNU/kFreeBSD we have a limitation of not being able to boot from an "msdos logical" partition (e.g. /dev/sda5+), although it might depend what filesystem is being used. Thanks to GRUB2's flexibility we can boot if at least either the root or /boot filesystem (I can't remember which) is on an "msdos primary" partition. FreeBSD and PC-BSD might not be able to do that. Regards, -- Steven Chamberlain [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
