Date: Tue, 04 Dec 2001 13:23:40 -0500 From: Bosko Milekic <bmilekic@dsuper.net> To: Luigi Rizzo <luigi@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <3C0D14AC.412D674C@dsuper.net> References: <200112040213.fB42DBl08877@freefall.freebsd.org> <20011203214418.A87350@technokratis.com> <20011203184737.D48755@iguana.aciri.org> <20011203222303.A2690@technokratis.com> <20011203205623.B49974@iguana.aciri.org> <20011204090509.A8591@technokratis.com> <20011204083922.B54383@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote:
> > at doing is solved. The message in subr_mbuf.c is therefore one of two
> > things: eithe rmisleading or redundant. If you need to increase
>
> it covers all cases where mb_alloc() fails, including the one
> above. We could special-case the MT_NOTMBUF one to prevent
> reporting in that case, but i doubt it is worth the effort.
No, I think that you're mis-understanding me. The message is either
redundant or mis-leading. Let me elaborate again:
- You wind up in the code path that prints your message in subr_mbuf.c
in, ultimately, one of these cases:
1. You're out of address space in mbuf_map and/or clust_map.
2. You're out of address space in kern_map (or whatever it is malloc(9)
allocates from - either that or kmem_map).
3. You're out of physical memory and you're calling with M_DONTWAIT.
One way or another, you're there because one of those 3. So, let's
look
at each one in turn.
In the case of (1), the message is already covered in vm/vm_kern.c.
In the case of (2), the message doesn't belong in subr_mbuf.c, for two
reasons: (i) It's not an mb_alloc() problem, you're likely to be having
a
TON of other problems, maybe you've already paniced or faulted somewhere
anyway; (ii) It's not solvable by increasing NMBCLUSTERS, if in doubt,
see (i) for the reason.
In the case of (3), it's as you previously mentionned: you're screwed
anyway. You're out of physical memory. But, even more importantly, the
reason the message doesn't belong in subr_mbuf.c is similar to (2),
it's not an mb_alloc() problem and it's not fixable with an increase
in NMBCLUSTERS. So, you see, I'm going to eventually wind up with
people having all sorts of wierd problems due to lack of physical
memory or lack of address space for malloc(9) to allocate from (the
latter is, admittedly less likely), and they're going to see these
messages about increasing NMBCLUSTERS or mbuf failures, and run off
screaming "it's the mbuf allocator, it's the mbuf allocator!" like
headless chicken, and wondering why them steadily increasing
NMBCLUSTERS is having no effect.
I hope you realize that I'm not being a pedantic bastard here for
no reason. It's certainly justified. I'm not against more warnings
and rate-limited printf()s. I think they are cool, but in this case,
I don't think that the problem is being addressed at its root. The
only time the user can re-tune their machine in the mbuf case is
when they are out of address space in one of the maps the allocator
is using. So, if the problem is not there, then it's somewhere else,
and it's somewhere else that it should be addressed (i.e. see adding
a rate-limited printf() in malloc(9) code).
> cheers
> luigi
> ----------------------------------+-----------------------------------------
> Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa)
> http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
> Phone: (510) 666 2927
> ----------------------------------+-----------------------------------------
I hope this clears up the issue...
Cheers,
Bosko.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C0D14AC.412D674C>