Date: Mon, 3 Dec 2001 20:56:23 -0800 From: Luigi Rizzo <luigi@FreeBSD.ORG> To: Bosko Milekic <bmilekic@technokratis.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <20011203205623.B49974@iguana.aciri.org> In-Reply-To: <20011203222303.A2690@technokratis.com> References: <200112040213.fB42DBl08877@freefall.freebsd.org> <20011203214418.A87350@technokratis.com> <20011203184737.D48755@iguana.aciri.org> <20011203222303.A2690@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 03, 2001 at 10:23:03PM -0500, Bosko Milekic wrote: > Actually, I was vouching for the removal of the change(s) in > subr_mbuf.c for two reasons: I read the exact opposite, and it did make sense to me to remove the code in vm_kern.c and keep the one in subr_mbuf.c The test i was running was on a system with 64MB of memory and a voluntarily low number of clusters (to see if error msgs would come out without crashing the box), and incomnig traffic on the interface. In this case (which I think is pretty common, or at least not a rare one), all allocations are attempted with M_NOWAIT and you can be assured the code was triggering in on every single incoming packet, so it really needs to be rate limited (which doesn't cost anything, have you seen how I have implemented it ?). And the msg in vm_kern.c did give the correct suggestion. If you are short of RAM, you are screwed anyways! Given that a single printf in subr_mbuf.c covers all cases, i do believe we should really keep this one. cheers luigi > 1. They can be mis-leading, i.e. the solution in that case is rarely to > increase mbuf_map and clust_map sizes (at this point, the failure > may actually be due to malloc() failing to allocate a bucket or lack > of RAM, not virtual address space in mbuf and clust maps). > > 2. The printf() in vm/vm_kern.c should more than cover it. Even that > one (the one in vm/vm_kern.c) doesn't really need to be rate > limited, because mb_alloc() is smart enough to figure out that if it > fails allocating with kmem_malloc() when the allocation is with > M_WAITOK, that it is due to lack of virtual address space in either > mbuf_map or clust_map and will stop calling kmem_malloc() for the > given map any more -- but if you really want you can leave the one > in vm/vm_kern.c there--- it doesn't really bother me as much as the > first one). > > As for -STABLE, it may have more validity, I haven't looked yet. > > > cheers > > luigi > > Cheers, > -- > Bosko Milekic > bmilekic@technokratis.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe cvs-all" in the body of the message 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?20011203205623.B49974>