From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:54:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BB4F16A419; Fri, 4 Jan 2008 12:54:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1700913C4DB; Fri, 4 Jan 2008 12:53:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9F4EA17105; Fri, 4 Jan 2008 12:53:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04Crvx6005648; Fri, 4 Jan 2008 12:53:57 GMT (envelope-from phk@critter.freebsd.dk) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Jan 2008 13:45:29 +0100." <86myrlahee.fsf@ds4.des.no> Date: Fri, 04 Jan 2008 12:53:57 +0000 Message-ID: <5647.1199451237@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, Robert Watson , Jason Evans , Igor Mozolevsky Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:54:00 -0000 In message <86myrlahee.fsf@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >"Igor Mozolevsky" writes: >> Broadcasting SIGDANGER would be a much better option; followed by >> SIGTERM to the memory hogger (to allow for graceful termination) and >> only then SIGKILL. I can imagine a few (legitimate) scenarios when a >> user process would want to hog as much RAM as possible... > >We don't currently have SIGDANGER, but the signal code was rewritten >years ago to allow more than 32 signals precisely for the purpose of >implementing an AIX-like SIGDANGER. This wasn't done, however, and >eventually SIGTHR was the first new signal to take advantage of the >rewritten code. SIGDANGER is not what we need. What we need is an intelligent mechanism to tell applications what the overall situation is, so that jemalloc and aware applications can tune their usage pattern to the availability of physical and virtual memory. Instead of the binary "SIGDANGER" indication we need a more gradual state, at the very least three stats: "plenty", "getting a bit tight" and "crunchtime". Having a signal to indicate changes of the state may make sense, but in a crunch, you don't want to wake all processes and page them in, just to tell them that you're short on memory, it would have to be a signal that doesn't schedule the recipient process until something else does. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.