Re: [SLUG] Kernel Memory Question

From: Russell Hires (rhires@earthlink.net)
Date: Tue Apr 10 2001 - 11:44:24 EDT


I don't know about the dirty part, but I do know that the kernel uses all
available memory. It takes everything you have available, including swap,
for its own use. That way, it's in control. Naturally, when you add memory,
the kernel takes it. I think (IIRC) that this actually makes the kernel more
efficient.

Russell

____________________________________________________
      "I don't care if you're going nowhere,
       Just take good care of the world."
                            -- Depeche Mode

----------
>From: Ed Centanni <ecentan1@tampabay.rr.com>
>To: slug@nks.net
>Subject: Re: [SLUG] Kernel Memory Question
>Date: Tue, Apr 10, 2001, 7:52 AM
>

> Norbert Cartagena wrote:
>>
>> Ed Centanni wrote:
>> >
>> > When I take a look at /proc/meminfo (kernel version 2.4.0 (4GB RAM
>> > enabled) I find that almost a third of my RAM is classified as
>> > "Inact_dirty". Does anyone have a good explanation of what this means.
>> > The kernel source code "fs/proc/proc_misc.c" gets this value from
>> > K(nr_inactive_dirty_pages).
>> >
>> > Please -- no porn site jokes.
>> >
>> > TIA
>> > Ed.
>>
>> This might not be of much, but have you checked out O'Reilly's Book on
>> the Linux Kernel (I believe it's called "Linux Kernel Internals")? That
>> might have some info. If you can't get to it soon I'll see if I can find
>> out something for you netx time I make my usual Barness and Noble
>> Hermitage ;)
>>
>
> Thanks. After posting the question I dug deeper into my vast
> underground caverns of links and I did find some information here:
> http://umeet.uninet.edu/conferencias/27-11-2000/2711.html
> and here:
> http://www.surriel.com/lectures/mmtour.html
> That pretty much answers my question. If anyone's interested I'll
> share.
>
>> P.S.
>> Can you post your /proc/meminfo file? I'd like to compare some notes
>> I've been looking at.
>>
>
> Here it is:
>
> total: used: free: shared: buffers: cached:
> Mem: 327245824 317763584 9482240 0 51363840 67473408
> Swap: 139821056 1118208 138702848
> MemTotal: 319576 kB
> MemFree: 9260 kB
> MemShared: 0 kB
> Buffers: 50160 kB
> Cached: 65892 kB
> Active: 29384 kB
> Inact_dirty: 83756 kB
> Inact_clean: 2912 kB
> Inact_target: 76 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 319576 kB
> LowFree: 9260 kB
> SwapTotal: 136544 kB
> SwapFree: 135452 kB
>
> The Inact_dirty was higher before I did a few experiments and reduced
> it. The experiments confirmed the information I got from the links.
> What's interesting is that large numbers in this class of memory
> shouldn't show up on systems where RAM is low enough to causing
> swapping. Only systems with "RAM to burn" will have significant numbers
> in this class. One could consider it a symption of "too much RAM". It
> also shows up a bug in xosview that shows more memory being used as
> "user or share" under such conditions than is true.
>
> The way this all started is that I upgraded the RAM on my system from 64
> Meg to 320. After being up 24 hours or so xosview reported that most of
> my memory (2/3) was being used by "user/share" programs and libraries
> and didn't change after I logged off and back on to release all loaded
> programs and shared libraries I use. Some kind of unknown executable
> appeared to be hogging almost 100Meg of RAM. Fearing a crack I started
> to investigate memory usage and thus this journey. It's really just
> memory that used to be occupied by executables but hasn't yet been
> reclaimed for re-use. The kernel delays reclaimation until the memory
> is needed again.
>
> All's well except for misleading and simplistic info from xosview.
>
> Ed.
>
>> P.P.S.
>> Long shot, but here goes (this is why I left it for last):
>> Do you have this message during bootup?
>>
>> "Kernel command line: keepinitrd"
>>
>
> No.
>
> <snip>



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:26:30 EDT