This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Feb 7 22:17:22 2023 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HKQAi23484 for ; Tue, 17 Sep 2002 22:26:13 +0200 Received: (qmail 23875 invoked from network); 17 Sep 2002 20:09:44 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 17 Sep 2002 20:09:44 -0000 Received: (qmail 19647 invoked by uid 1000); 17 Sep 2002 19:44:46 -0000 MBOX-Line: From linux-kernel-owner@vger.kernel.org Tue Oct 10 07:21:14 2000 Received: (maildatabase); juh Received: (qmail 845 invoked by alias); 10 Oct 2000 06:56:08 -0000 Received: (qmail 647 invoked from network); 10 Oct 2000 06:52:27 -0000 Received: from server.ds9a.tudelft.nl (HELO home.ds9a.nl) (10.0.0.1) by spaans.ds9a.nl with SMTP; 10 Oct 2000 06:52:27 -0000 Received: (qmail 11150 invoked by uid 0); 9 Oct 2000 22:46:55 -0000 Received: from vger.kernel.org (199.183.24.194) by home.ds9a.nl with SMTP; 9 Oct 2000 22:46:55 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 9 Oct 2000 18:05:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 9 Oct 2000 18:05:18 -0400 Received: from neon-gw.transmeta.com ([209.10.217.66]:52232 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Mon, 9 Oct 2000 18:05:09 -0400 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id OAA31175; Mon, 9 Oct 2000 14:51:20 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma031169; Mon, 9 Oct 00 14:50:53 -0700 Received: from penguin.transmeta.com (penguin.transmeta.com [10.1.2.202]) by deepthought.transmeta.com (8.9.3/8.9.3) with ESMTP id OAA12727; Mon, 9 Oct 2000 14:50:55 -0700 (PDT) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.9.3/8.7.3) with ESMTP id OAA06727; Mon, 9 Oct 2000 14:50:55 -0700 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Mon, 9 Oct 2000 14:50:51 -0700 (PDT) From: Linus Torvalds To: Jim Gettys Cc: Alan Cox , Andi Kleen , Ingo Molnar , Andrea Arcangeli , Rik van Riel , Byron Stanoszek , MM mailing list , linux-ker Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler In-Reply-To: <200010092144.OAA02051@pachyderm.pa.dec.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 9 Oct 2000, Jim Gettys wrote: > > > On Date: Mon, 9 Oct 2000 14:38:10 -0700 (PDT), Linus Torvalds > said: > > > > > The problem is that there is no way to keep track of them afterwards. > > > > So the process that gave X the bitmap dies. What now? Are we going to > > depend on X un-counting the resources? > > > > X has to uncount the resources already, to free the memory in the X server > allocated on behalf of that client. X has to get this right, to be a long > lived server (properly debugged X servers last many months without problems: > unfortunately, a fair number of DDX's are buggy). No, but my point is that it doesn't really work. One of the biggest bitmaps is the background bitmap. So you have a client that uploads it to X and then goes away. There's nobody to un-count to by the time X decides to switch to another background. Does that memory just disappear as far as the resource handling is concerned when the client that originated it dies? What happens with TCP connections? They might be local. Or they might not. In either case X doesn't know whom to blame. Basically, the only thing _I_ think X can do is to really say "oh, please don't count my memory, because everything I do I do for my clients, not for myself". THAT is my argument. Basically there is nothing we can reliably account. So we might as well fall back on just saying "X is more important than some random client", and have a mm niceness level. Which right now is obviously approximated by the IO capabilities tests etc. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/