[Openswan Users] kernel memory leak 2.4.7, 2.4.33 - misconfiguration or bug? (fwd)

[Brad Langhorst]

On Fri, 2007-05-11 at 18:30 -0400, Brad Langhorst wrote:
> On Fri, 2007-05-11 at 17:49 -0400, Michael Richardson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > Hi, can you run the slabwatch during the transfer?
> > Sometimes things aren't running out, but go short while in use.
> > (and get cleaned up later on). But, if the later on never happens.
> > 
> > But, you show the memory disappearing in the free output.
> > And no processes are getting bigger?
> exactomundo, there are tiny changes in the vmsize reported by ps aux,
> but no where near enough to account for all the lost free memory.
> 
> I have some new information...
> Once the time synced up exactly between the machines (which took quite a
> while) the memory leak nearly disappears (only 4 Bytes for the same 20M
> transfer).  I can duplicate it if i turn off ntpd and set the clocks
> different.

I spoke too soon...
I'm still seeing a big loss in free memory during the overnight
transfer. I think i must have done that last test in the wrong
direction.

I now believe that the vmsize reported in slabinfo is kbytes not bytes.
even though man slabinfo says it's in bytes

> For each slab cache, the cache name, the number of currently active
> objects, the total number of  available  objects, the  size of each
> object in bytes, the number of pages with at least one active object,
> the total number of allocated pages, and the number of pages per slab
> are given.

+echo >>skbuff_head_cache 42101 42108
 
+echo >>size-1024 41705 41708

I guess this is where the 80+ M or missing ram is.
is that correct?

brad



-- 
Brad Langhorst
CTO - CoopMetrics