Hello all:
Having had some issues with my laptop, I've been doing some reading through my
personal archives of the gentoo-user mailing list on the subject of memory
management.
On Thursday 23 September 2004 11:03 pm, Collins Richey wrote:
> The first thing you should understand is that the phenomenon you are
> describing is quite normal. Linux does not as a rule free memory until
> it is needed for something else. Thus, as you continue to run various
> programs during the day, memory will remain allocated until you have
> exhausted memory, then linux will reclaim what is needed to make room
> for something new. A similar principle applies for data in the I/O
> buffers. If you want to see this in action, try a find command in a
> directory with a large number of files/directories. It takes a while.
> Then repeat the same command. It takes much less time to complete,
> because much of the data needed is still in the I/O buffers.
A very good explanation for a newbie, Collins; thank you.
Still, I have some questions about why it still _feels_ as though my system is
lagging, as well as a few possible reasons why it very well may be due to a
kernel misconfiguration of my own. However, I'm unsure of the best way to fix
them.
After running a significantly taxing process such as a compile, or moving
large 1.1 GB files across various partitions on my file system (Neverwinter
Nights is ungodly huge, even when tarballed), I find that my 1 GB of RAM is
very nearly used up. When the process completes, or when I stop X, the
allocated RAM is still cached according to top, just as would be predicted by
Collins' above statement.
When I restart X or begin another large process, the amount of "free RAM"
stays virtually the same, ~4 MB. This makes sense, too: Linux only frees
enough cached RAM as it needs; therefore, the amount of RAM freed to run the
new process is completely taken up by that new process. However, that new
process tends to run slower than before it did before running the compile.
Problem is, I don't have any numbers to prove it ... just how it _feels_.
Perhaps the problem isn't in memory management. I know that my processor has
been having problems keeping track of time. When I run dmesg, I get the
following (the first line repeats several times):
--- dmesg output ---
Losing some ticks... checking if CPU frequency changed.
Losing too many ticks!
TSC cannot be used as a timesource.
Possible reasons for this are:
You're running with Speedstep,
You don't have DMA enabled for your hard disk (see hdparm),
Incorrect TSC synchronization on an SMP system (see dmesg).
Falling back to a sane timesource now.
--- dmesg output ---
I'm running gentoo-dev-sources-2.6.8-r10 on an SMP system (actually, a 3.2
Pentium 4 w/ Hyperthreading). I tried checking hdparm, and apparently, DMA is
disabled for all of my partitions, and try as I might, I cannot turn it on. I
even tried setting it to the always on position somewhere in the kernel
configuration, but it still doesn't work. TSC also appears to be a problem,
and I don't know how to check if I am in fact running with Speedstep.
I don't know if these two problems are related, or even if the first truly is
a problem.
Anyone, any ideas?
Thanks everyone for your help.
Kris Kerwin
--
gentoo-user@gentoo.org mailing list
Having had some issues with my laptop, I've been doing some reading through my
personal archives of the gentoo-user mailing list on the subject of memory
management.
On Thursday 23 September 2004 11:03 pm, Collins Richey wrote:
> The first thing you should understand is that the phenomenon you are
> describing is quite normal. Linux does not as a rule free memory until
> it is needed for something else. Thus, as you continue to run various
> programs during the day, memory will remain allocated until you have
> exhausted memory, then linux will reclaim what is needed to make room
> for something new. A similar principle applies for data in the I/O
> buffers. If you want to see this in action, try a find command in a
> directory with a large number of files/directories. It takes a while.
> Then repeat the same command. It takes much less time to complete,
> because much of the data needed is still in the I/O buffers.
A very good explanation for a newbie, Collins; thank you.
Still, I have some questions about why it still _feels_ as though my system is
lagging, as well as a few possible reasons why it very well may be due to a
kernel misconfiguration of my own. However, I'm unsure of the best way to fix
them.
After running a significantly taxing process such as a compile, or moving
large 1.1 GB files across various partitions on my file system (Neverwinter
Nights is ungodly huge, even when tarballed), I find that my 1 GB of RAM is
very nearly used up. When the process completes, or when I stop X, the
allocated RAM is still cached according to top, just as would be predicted by
Collins' above statement.
When I restart X or begin another large process, the amount of "free RAM"
stays virtually the same, ~4 MB. This makes sense, too: Linux only frees
enough cached RAM as it needs; therefore, the amount of RAM freed to run the
new process is completely taken up by that new process. However, that new
process tends to run slower than before it did before running the compile.
Problem is, I don't have any numbers to prove it ... just how it _feels_.
Perhaps the problem isn't in memory management. I know that my processor has
been having problems keeping track of time. When I run dmesg, I get the
following (the first line repeats several times):
--- dmesg output ---
Losing some ticks... checking if CPU frequency changed.
Losing too many ticks!
TSC cannot be used as a timesource.
Possible reasons for this are:
You're running with Speedstep,
You don't have DMA enabled for your hard disk (see hdparm),
Incorrect TSC synchronization on an SMP system (see dmesg).
Falling back to a sane timesource now.
--- dmesg output ---
I'm running gentoo-dev-sources-2.6.8-r10 on an SMP system (actually, a 3.2
Pentium 4 w/ Hyperthreading). I tried checking hdparm, and apparently, DMA is
disabled for all of my partitions, and try as I might, I cannot turn it on. I
even tried setting it to the always on position somewhere in the kernel
configuration, but it still doesn't work. TSC also appears to be a problem,
and I don't know how to check if I am in fact running with Speedstep.
I don't know if these two problems are related, or even if the first truly is
a problem.
Anyone, any ideas?
Thanks everyone for your help.
Kris Kerwin
--
gentoo-user@gentoo.org mailing list