From owner-cvs-all Tue Dec 4 10:23:56 2001 Delivered-To: cvs-all@freebsd.org Received: from water.cc.mcgill.ca (water.CC.McGill.CA [132.206.27.29]) by hub.freebsd.org (Postfix) with ESMTP id 0DFEE37B416; Tue, 4 Dec 2001 10:23:49 -0800 (PST) Received: from dsuper.net (clio.Emf.McGill.CA [132.216.48.159]) by water.cc.mcgill.ca (8.12.1/8.11.0) with ESMTP id fB4INmZK022738; Tue, 4 Dec 2001 13:23:48 -0500 (EST) Message-ID: <3C0D14AC.412D674C@dsuper.net> Date: Tue, 04 Dec 2001 13:23:40 -0500 From: Bosko Milekic X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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