[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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):

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.

Steven Chamberlain

Reply to: