Date: Tue, 4 Dec 2001 09:05:09 -0500 From: Bosko Milekic <bmilekic@technokratis.com> 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: <20011204090509.A8591@technokratis.com> In-Reply-To: <20011203205623.B49974@iguana.aciri.org>; from luigi@FreeBSD.org on Mon, Dec 03, 2001 at 08:56:23PM -0800 References: <200112040213.fB42DBl08877@freefall.freebsd.org> <20011203214418.A87350@technokratis.com> <20011203184737.D48755@iguana.aciri.org> <20011203222303.A2690@technokratis.com> <20011203205623.B49974@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 03, 2001 at 08:56:23PM -0800, Luigi Rizzo wrote: > 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. The message in vm/vm_kern.c covers all the cases that are solved by increasing NMBCLUSTERS. If it's rate limited, then what you are looking 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 NMBCLUSTERS, you'll always hit the message in vm/vm_kern.c at least once, and all you really want is to hit it once. After that, if you haven't noticed, your connections will start to hang and make sure that you have. > 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 > -- Bosko Milekic bmilekic@technokratis.com 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?20011204090509.A8591>