Re: Two questions about kfreebsd
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
steven@pyro.eu.org
Reply to: