I really doubt you'll find anything interesting investigating our
kernel modifications for sources of memory leaks. I just personally
audited Cirrus' ethernet driver and found only 2 calls to "kmalloc"
and those are only at driver initialization and total less than a
few kilobytes. Anything that appears to "leak" relating to network
function would have to be at untouched (by Cirrus or TS) 2.4.26
areas of Linux kernel code.
If you could provide more evidence than just the notoriously
unreliable "free" command output that memory is being permanently
lost, that would be great. For instance, if you suspect leaking X
MB / Y hrs and have 32 MB of RAM total in 32 / X * Y hrs your system
should be out of memory and really start malfunctioning in ways that
would be very interesting for the original Linux VM authors (and
this group) to know about.
The VM system is somewhat unique on this processor since it uses a
subsystem rarely used on Linux/x86 for handling discontiguous memory
blocks. We've already found and fixed one bug in the original
code. Its severity made me doubt the level of testing and quality
of thought the 2.4.26 authors originally put into it, so I wouldn't
be surprised if it has other quirks regarding memory usage
reporting. If its actually responsible for leaking memory (which I
still doubt), my feeling of general unease about quality will be
replaced with outrage ;-) -- though really its kind of hard to get
mad with something thats free and has no warranty. :-)
//Jesse Off
--- In "rsmckown" <> wrote:
>
> --- In "dawydiuk" <eddie@> wrote:
> >
> > Hello,
> >
> > > Here's a summary of the free command output at 0 hours and 46
> > > hours into the test:
> > >
> > > used free buf cached
> > > 0 hrs 15568 13304 788 8788
> > > 46hrs 25004 3568 2500 10112
> > >
> > > You'll notice that buffer/cache allocations increase, but not
> > > nearly enough to account for the decrease in free memory.
> > >
> > "The short answer is that you should never worry about the
amount of
> > free memory on Linux. The kernel attempts to keep this slightly
> > above zero by keeping the cache as large as possible. This is a
> > feature not a bug."
> >
> > Why doesn't free memory go down
> > http://sourcefrog.net/weblog/software/linux-kernel/free-mem.html
>
> We make network appliances that run the linux kernel. Take a look
at
> this output from one of those machines, which is a live
> router/firewall in our company's network (and note its uptime):
>
> /root]# uptime
> 19:38:11 up 83 days, 2:51, load average: 0.07, 0.01, 0.00
> /root]# cat /proc/meminfo [output trimmed]
> MemTotal: 61992 kB
> MemFree: 30204 kB
> MemShared: 0 kB
> Buffers: 3920 kB
> Cached: 13840 kB
>
> In light of the quote you took from Martin Pool's blog, why is
there
> so many pages on the free list (MemFree)? For two reasons: (1)
kernel
> and user threads haven't made enough allocations to consume more,
and
> (2) current processing requirements require no more cache/buffer
> blocks (Buffers + Cached) than are being used.
>
> The quote is taken out of context. It assumes a busy machine with
> swap space, where the VM subsystem balances cached pages, active
> in-core pages and active out-of-core pages in an effort to keep as
> many of the the most relevant pages in RAM as possible.
>
> Take a look at the memory output for the TS-7200 at the very top of
> this e-mail. You'll notice that in the time the free list was
reduced
> by about 10MB, only 4MB of which is accounted for by increased
buffer
> and cache page usage. This leaves 6MB allocated elsewhere, which
is
> a behavior I haven't seen before. Also note that allocations would
> most likely have continued had I not stopped the test. This
behavior,
> continuous increases in allocations that grow statistically large
over
> time, is symptomatic of a memory leak. It could be something else,
> but it doesn't seem likely.
>
> Because the running processes don't seem to be accumulating memory
> blocks, I presume the allocations are happening in the kernel.
This
> leads me to suspect the modifications that have been made to
support
> the EP9302, or a kernel module for this platform.
>
> I'll be looking into this over the next few weeks and will let you
> know what I find. If there's anyone out there that has TS-7200's
with
> uptimes measured in weeks or months, It'd be helpful to learn more
> from you to better target my research.
>
> All the best,
> Steve
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|