Date: Fri, 11 Oct 2002 15:35:38 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Ben Stuyts <ben@stuyts.nl>, Robert Watson <rwatson@freebsd.org>, current@freebsd.org, jeff@freebsd.org Subject: Re: [Ugly PATCH] Re: Again: panic kmem_malloc() Message-ID: <3DA7523A.A18BCE11@mindspring.com> References: <20021011162439.P46092-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote: > On Fri, 11 Oct 2002, Terry Lambert wrote: > > Ben Stuyts wrote: > > > Is there a way to check the free list of the kernel? Maybe I can find out > > > what action triggers eating al its memory. > > Maybe you should just increase the size of your kmem_map? I'll look into > a better fix but that should do it short term. I think he's in an overload condition. Basically, it will always use all available resources, and then some. So incresing "all available" still leaves you with your foot shot off when the system asks for "and then some". 8-(. > > 1) page_alloc() in uma is using kmem_malloc() without the > > M_NOWAIT flag > > Why is this bogus? Because it's possible to panic under heavy load. The only thing heavy load should cause is slowdown... ideally, proportional to the load... ;^). > Yes, I agree, it should wait. It might be interesting to see what the > effects of allocating straight out of the kernel_map would be. Or perhaps > positioning the kmem_map in such a way that it might be able to expand. I > don't like the hard limit here anymore than anyone else does. I looked at this. I don't think you can reasonable expand maps other than the kernel_map. The allocations are wrong... kernel_map is, unfortunately, "special". This is about the 1,000,000th time I've wanted to establish mappings for all physical RAM, and maybe the entire address space, up front, instead of leaving it to demand-time. The problem with this is that you are talking 4M (or 8M, if you use PSE-36 or PAE). Then *everything* becomes allocable at interrupt time, and there's no such thing as tiered access semantics, only whether or not a mapping is assigned to the pool you want to allocate out of, or not. > On reasonable architectures your only worry is wasting pages and not kva. Heh... "It's not an unreasonable architecture, you're just using an unreasonable amount of memory on a reasonable architecture". > > Jeffrey Roberson is going to need to fix UMA allocations, per the > > comment in this patch, for a more permanent fix. I've specifically > > Cc:'ed him on this message. > > Thanks for looking into this terry. Please, call me Jeff though. No problem; I copied the name out of the source file; I tend to use "Terrence" in source files (you can see this in init_main.c and other places where I did enough work I felt it merited a copyright to be able to give it away). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DA7523A.A18BCE11>