Re: why does the kernel suck up memory?
Klaus Wacker writes: [snip] Thanks for you reply. Strangely enough, the original problem of all physical ram being allocated was solved by upgrading the kernel from 2.0.30 to 2.0.33 Just wanted everyone to know 8-) -- -= Sent by Debian 1.3 Linux =- Thomas Kocourek KD4CIK @[EMAIL PROTECTED]@westgac3.dragon.com Remove @_@ for correct Email address --... ...-- ... -.. . -.- -.. - -.-. .. -.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does the kernel suck up memory?
Klaus Wacker wrote: On Tue, Mar 31, 1998 at 12:18:19AM -0600, Mike Brownlow wrote: I am having the reverse problem on my machine at work. It doesn't want to use the swap partition at all unless I force it to. [ some stuff ] I would compile it [xfree86] from source but the same problems happen during a compile. I had to reboot several times to get the kde and kernel sources to finish. This looks very similar to the problem I had before I changed my motherboard (or before I switched off 2nd level cache on my old motherboard). I.e., I suspect it is a hardware problem. How does the compilation stop, with signal 11? Yes it think it was sig 11. But I haven't done any major hardware changes on it (IOW, it worked ok with RedHat). I upgraded the ram a while back tho. Recently I've been able to use it when I come back into work. But if I quit X, the only way to get it back is with a reboot. I'll double check the MB's settings though. I tried overclocking it a while back and that proved unsuccessful. Maybe I forgot a jumper somewhere... I am using a script which compiles the kernel 100 times to test my hardware. I had a probability of a signal 11 crash of gcc about every 3 or 4 times. When a crash happened, further invocations of gcc would usually crash immediately, so the remainder of the loop ran through very quickly. To get better statistics, I added a program like you describe after each compilation. This has the effect of forcing the (presumably damaged) gcc executable out of the memory buffer and a reload of a fresh copy from disk, so the loop could continue. -- Klaus Wacker [EMAIL PROTECTED] 51°29'9N 7°25'9E http://www.physik.uni-dortmund.de/~wacker Cool. I'll have to write that memory grabber program again. I'll also try the mem=48 line as suggested by: Fabien Ninoles wrote: May be this pointer can help a little bit (sorry if not): /usr/src/linux/Documentation/memory-tuning.txt Maybe even stick that memory grabber in cron? My disk will probably die soon though. -mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does the kernel suck up memory?
George Bonser wrote: On Mon, 6 Apr 1998, Mike Brownlow wrote: Yes I think it was sig 11. But I haven't done any major hardware changes on it (IOW, it worked ok with RedHat). I upgraded the ram a while back tho. I have had considerable trouble with sig 11 faults while running the newer kernels and compiling and I think I might have discovered what it is: CPU overheating. I wanted to wait until I tested things a bit more before I said this but I am almost convinced now that my problem on the 486 machine is a bad fan and on the other machine it is also a weak fan and running the rc5 cracking process at a high priority. Now this is interesting. There are no fans inside my box at work. Only a heatsink. Well, there's the P/S fan. But that's it. I'll have to try this tomorrow too, err..today rather. My box at home has 3 fans and I rarely have any problems. The one at work is a P133(debian). At home it's a 6x86MX PR200(slack (soon to be debian (ahh! nested parens!))). Thanks for all the help! -mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does the kernel suck up memory?
On Tue, Mar 31, 1998 at 12:18:19AM -0600, Mike Brownlow wrote: I am having the reverse problem on my machine at work. It doesn't want to use the swap partition at all unless I force it to. I suppose that is a good thing, but what about: When I go into work I'll switch virt. consoles or type in an xterm and *poof*, there goes the X server. Then I try to run X again and it quits just as it's about to spawn the window manager. Then after I reboot, X starts up fine. This has happened every day since I've ftp-installed debian 1.3. On my previous dist I wrote a program in c that when run as root from a console will allocate all of my available memory and swap and then free it up. After doing this I was able to start X again. But I lost the code when I moved from redhat - debian. The reason I had the code on redhat was for the same problem. But it occured infrequently. Is there something I should upgrade? I have been planning to upgrade Xfree86 to 3.3.2 but I am still a newbie with dselect, etc. I would compile it from source but the same problems happen during a compile. I had to reboot several times to get the kde and kernel sources to finish. This looks very similar to the problem I had before I changed my motherboard (or before I switched off 2nd level cache on my old motherboard). I.e., I suspect it is a hardware problem. How does the compilation stop, with signal 11? I am using a script which compiles the kernel 100 times to test my hardware. I had a probability of a signal 11 crash of gcc about every 3 or 4 times. When a crash happened, further invocations of gcc would usually crash immediately, so the remainder of the loop ran through very quickly. To get better statistics, I added a program like you describe after each compilation. This has the effect of forcing the (presumably damaged) gcc executable out of the memory buffer and a reload of a fresh copy from disk, so the loop could continue. BTW, can someone explain the difference between buffers and cached to me? -- Klaus Wacker [EMAIL PROTECTED] 51°29'9N 7°25'9E http://www.physik.uni-dortmund.de/~wacker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does the kernel suck up memory?
On Thu, Apr 02, 1998 at 10:59:12PM +0200, Klaus Wacker wrote: I am using a script which compiles the kernel 100 times to test my hardware. I had a probability of a signal 11 crash of gcc about every 3 or 4 times. When a crash happened, further invocations of gcc would usually crash immediately, so the remainder of the loop ran through very quickly. To get better statistics, I added a program like you describe after each compilation. This has the effect of forcing the (presumably damaged) gcc executable out of the memory buffer and a reload of a fresh copy from disk, so the loop could continue. Hugh! This can be really stressful effectively... I don't think NT can do the same (if you ever seen it just recovery from a PANIC... it's most of the time just PANIC again ;). BTW, can someone explain the difference between buffers and cached to me? May be this pointer can help a little bit (sorry if not): /usr/src/linux/Documentation/memory-tuning.txt For sure, this doesn't help for hardware problems but I have quiet better performance on my linux after following this little guide. -- Klaus Wacker [EMAIL PROTECTED] 51°29'9N 7°25'9E http://www.physik.uni-dortmund.de/~wacker -- Fabien Ninoles E-mail: [EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 You can get my public key from your nearest public keys server! RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 pgpjBjoUhusox.pgp Description: PGP signature
Re: why does the kernel suck up memory?
jim wrote: I have trouble with the idea that a swap partition is never dropped once it is accessed, especially in light of the following: osiris# cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 48283648 42934272 5349376 28479488 1650688 16846848 Swap: 949575680 94957568 MemTotal: 47152 kB MemFree: 5224 kB MemShared:27812 kB Buffers: 1612 kB Cached: 16452 kB SwapTotal:92732 kB SwapFree: 92732 kB I am having the reverse problem on my machine at work. It doesn't want to use the swap partition at all unless I force it to. I suppose that is a good thing, but what about: When I go into work I'll switch virt. consoles or type in an xterm and *poof*, there goes the X server. Then I try to run X again and it quits just as it's about to spawn the window manager. Then after I reboot, X starts up fine. This has happened every day since I've ftp-installed debian 1.3. On my previous dist I wrote a program in c that when run as root from a console will allocate all of my available memory and swap and then free it up. After doing this I was able to start X again. But I lost the code when I moved from redhat - debian. The reason I had the code on redhat was for the same problem. But it occured infrequently. Is there something I should upgrade? I have been planning to upgrade Xfree86 to 3.3.2 but I am still a newbie with dselect, etc. I would compile it from source but the same problems happen during a compile. I had to reboot several times to get the kde and kernel sources to finish. Any help is greatly appreciated! :-) Machine: Kernel 2.0.33 X 3.3 Debian 1.3 48meg P133 -mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
why does the kernel suck up memory?
I've noticed that when I added more memory, the extra memory went into buffers. Why? I don't have a heavily loaded system which would require massive buffers. How can I change the kernel to stop with this unnecessary behavior? I'm trying to keep from using swap space. Once a swap partition is accessed, it is never dropped and I need to _not_ access swap space for performance reasons (IO bandwidth). -- -= Sent by Debian 1.3 Linux =- Thomas Kocourek KD4CIK @[EMAIL PROTECTED]@westgac3.dragon.com Remove @_@ for correct Email address --... ...-- ... -.. . -.- -.. - -.-. .. -.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does the kernel suck up memory?
On Mon, Mar 30, 1998 at 10:04:12AM -0500, [EMAIL PROTECTED] wrote: I've noticed that when I added more memory, the extra memory went into buffers. Why? I don't have a heavily loaded system which would require massive buffers. How can I change the kernel to stop with this unnecessary behavior? Think of those buffers as a dynamically growing cache that uses all available free memory on your machine. If some other process needs the memory the cache is shrunk. That's good behaviour there, nothing harmful. I'm trying to keep from using swap space. Once a swap partition is accessed, it is never dropped and I need to _not_ access swap space for performance reasons (IO bandwidth). Some parts of memory are not normally needed. Once those are swapped out, they'll propably never be swapped out. It's better that way, it frees memory to be used as cache. -- [EMAIL PROTECTED] - it's a valid address w/o spam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does the kernel suck up memory?
I've noticed that when I added more memory, the extra memory went into buffers. Why? I don't have a heavily loaded system which would require massive buffers. How can I change the kernel to stop with this unnecessary behavior? I'm trying to keep from using swap space. Once a swap partition is accessed, it is never dropped and I need to _not_ access swap space for performance reasons (IO bandwidth). Why would you add memory and not expect your operating system to use it. That would be a waste. The Linux kernel takes your memory and allows various parts of your system (such as disk IO) to speed up. DOS doesn't do that kind of memory monitoring, and in the case of Microsoft (not NT), free memory is useable memory. Because you memory is in cache and buffers does not mean that it will not get used if it is needed. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does the kernel suck up memory?
Jay Barbee writes: I've noticed that when I added more memory, the extra memory went into buffers. Why? I don't have a heavily loaded system which would require massive buffers. How can I change the kernel to stop with this unnecessary behavior? I'm trying to keep from using swap space. Once a swap partition is accessed, it is never dropped and I need to _not_ access swap space for performance reasons (IO bandwidth). Why would you add memory and not expect your operating system to use it. That would be a waste. The Linux kernel takes your memory and allows various parts of your system (such as disk IO) to speed up. DOS doesn't do that kind of memory monitoring, and in the case of Microsoft (not NT), free memory is useable memory. Because you memory is in cache and buffers does not mean that it will not get used if it is needed. --Jay I have trouble with the idea that a swap partition is never dropped once it is accessed, especially in light of the following: osiris# cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 48283648 42934272 5349376 28479488 1650688 16846848 Swap: 949575680 94957568 MemTotal: 47152 kB MemFree: 5224 kB MemShared:27812 kB Buffers: 1612 kB Cached: 16452 kB SwapTotal:92732 kB SwapFree: 92732 kB osiris# swapoff /dev/hda2 osiris# cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 48283648 42909696 5373952 28483584 1650688 16846848 Swap:000 MemTotal: 47152 kB MemFree: 5248 kB MemShared:27816 kB Buffers: 1612 kB Cached: 16452 kB SwapTotal:0 kB SwapFree: 0 kB If one really wants to avoid swap, why wouldn't one simply not have any swap partitions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
