Messages in this thread | | | Date | Wed, 5 Mar 2008 21:11:34 +0000 (GMT) | From | Hugh Dickins <> | Subject | Re: 2.6.25-rc3: 34TB vmalloc total -- overflow in /proc/meminfo? |
| |
On Wed, 5 Mar 2008, Christian Kujau wrote: > On Wed, 5 Mar 2008, Pavel Machek wrote: > > CommitLimit: 4132360 kB > > Committed_AS: 27684 kB > > VmallocTotal: 34359738367 kB > > VmallocUsed: 18112 kB > > VmallocChunk: 34359720115 kB
I don't see what Pavel's issue is with this: it's simply a fact that with a 64-bit kernel, we've lots of virtual address space to spare for vmalloc. What would be surprising is for VmallocUsed to get up as high as that.
> > out of curiosity: yesterday I've seen a box[0] with ~4 TB Committed_AS: > > CommitLimit: 3085152 kB > Committed_AS: 4281048084 kB > VmallocTotal: 118776 kB > VmallocUsed: 13772 kB > VmallocChunk: 103880 kB > > Since it's a rather old kernel (2.6.19.2), I just want to know: could this be > related to what you've seen or this completely different
Completely different and much more interesting.
> (and Committed_AS is > just this high because some st00pid app has allocated this much memory but not > freed again)?
Unlikely. Offhand I'm not quite sure that's impossible, but it's far more likely that we've a kernel bug and vm_committed_space has wrapped negative.
Ancient as your kernel is, I don't notice anything in the ChangeLogs since then to say we've fixed a bug of that kind since 2.6.19. Any idea how to reproduce this? Are you using HugePages at all? (It's particularly easy for us to get into a muddle over them, though historically I think mremap has proved most difficult for Committed_AS accounting).
Thanks, Hugh
> > Thanks, > Christian. > > [0] amd64, 32bit kernel, 32bit userland, 4GB RAM
| |