LKML Archive on
help / color / mirror / Atom feed
From: Hugh Dickins <>
To: Christian Kujau <>
Cc: Pavel Machek <>,
	kernel list <>,
	"Rafael J. Wysocki" <>
Subject: Re: 2.6.25-rc3: 34TB vmalloc total -- overflow in /proc/meminfo?
Date: Wed, 5 Mar 2008 23:21:08 +0000 (GMT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, 5 Mar 2008, Christian Kujau wrote:
> Well, if it's "interesting" are some more details from the box:

Thanks for putting that together; but I didn't find any clues.

> > 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.
> Huh. When I first saw this I thought "kernel bug" too, but then read the
> documentation to Committed_AS I thought it's just userspace related...

It's pretty sure to be userspace related i.e. kernel bug triggered by
particular userspace usage; and understandably, the bits you put there
don't tell me much about what userspace has been up to.  (And don't
worry, I'm not expecting you to tell me more!  I can't think of
anything useful to ask about it - it's not a question of what mix
of apps you have running there, it's a matter of what system calls,
especially mmaps, they make - I'm not expecting traces of that.)

> > 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?
> Well, the box is running fine and since it's a production machine I don't
> intend to reboot the box very often.

Absolutely.  You mentioned it because it's useful for us to know there's
such an issue about, to keep our eyes open: thank you for doing so.
No need for you to go any further out of your way on it.

> And since it's really an old kernel (for
> lkml discussion, that is) I don't intend to debug this one further. I really
> was only curious if this was userspace related (some app overcommitting) or
> some kernel weirdness.
> > Are you using HugePages at all?
> I have:
> # CONFIG_HUGETLBFS is not set
> # CONFIG_HUGETLB_PAGE is not set
> ...was this, what you meant?

Right, I was forgetting that the various "HugePage" lines of /proc/meminfo
don't even appear when those are configured off, so my question was more
obscure than I'd intended.  You're not using HugePages at all, so we
can rule out that line of inquiry - that's helpful, thanks.

I'll keep my eyes open.


      reply	other threads:[~2008-03-05 23:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-05  9:06 Pavel Machek
2008-03-05  9:36 ` Pavel Machek
2008-03-05  9:39   ` Pavel Machek
2008-03-05 22:12     ` Rafael J. Wysocki
2008-03-05 22:31       ` Andi Kleen
2008-03-06 11:14         ` Ingo Molnar
2008-03-06 11:30           ` Andi Kleen
2008-03-06 21:06             ` Ingo Molnar
2008-03-06 10:43       ` Pavel Machek
2008-03-05 19:49 ` Christian Kujau
2008-03-05 21:11   ` Hugh Dickins
2008-03-05 21:21     ` Pavel Machek
2008-03-05 21:36       ` Hugh Dickins
2008-03-05 22:11     ` Christian Kujau
2008-03-05 23:21       ` Hugh Dickins [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: 2.6.25-rc3: 34TB vmalloc total -- overflow in /proc/meminfo?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).