This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 00:24:59 2024 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 g8HKJvi17390 for ; Tue, 17 Sep 2002 22:19:59 +0200 Received: (qmail 20216 invoked from network); 17 Sep 2002 20:03:56 -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:03:56 -0000 Received: (qmail 17576 invoked by uid 1000); 17 Sep 2002 19:44:01 -0000 MBOX-Line: From linux-kernel-owner@vger.kernel.org Tue Oct 10 07:46:11 2000 Received: (maildatabase); juh Received: (qmail 2043 invoked by alias); 10 Oct 2000 07:21:17 -0000 Received: (qmail 1205 invoked from network); 10 Oct 2000 07:10:14 -0000 Received: from server.ds9a.tudelft.nl (HELO home.ds9a.nl) (10.0.0.1) by spaans.ds9a.nl with SMTP; 10 Oct 2000 07:10:14 -0000 Received: (qmail 11248 invoked by uid 0); 9 Oct 2000 23:04:42 -0000 Received: from vger.kernel.org (199.183.24.194) by home.ds9a.nl with SMTP; 9 Oct 2000 23:04:42 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 9 Oct 2000 18:22:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 9 Oct 2000 18:22:10 -0400 Received: from mail2.digital.com ([204.123.2.56]:17169 "EHLO mail2.digital.com") by vger.kernel.org with ESMTP id ; Mon, 9 Oct 2000 18:21:59 -0400 Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23]) by mail2.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id PAA09861; Mon, 9 Oct 2000 15:07:54 -0700 (PDT) Received: by pachyderm.pa.dec.com; id PAA08714; Mon, 9 Oct 2000 15:07:53 -0700 (PDT) Date: Mon, 9 Oct 2000 15:07:53 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Message-Id: <200010092207.PAA08714@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Linus Torvalds Cc: Jim Gettys , Alan Cox , Andi Kleen , Ingo Molnar , Andrea Arcangeli , Rik van Riel , Byron Stanoszek , MM mailing list < In-Reply-To: Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler Mime-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org > From: Linus Torvalds > Date: Mon, 9 Oct 2000 14:50:51 -0700 (PDT) > To: Jim Gettys > Cc: Alan Cox , Andi Kleen , > Ingo Molnar , Andrea Arcangeli , > Rik van Riel , > Byron Stanoszek , > MM mailing list , linux-kernel@vger.kernel.org > Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler > ----- > 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. Actually, the big offenders are things other than the background bitmap: things like E do absolutely insane things, you would not believe (or maybe you would). The background pixmap is generally in the worst case typically no worse than 4 megabytes (for those people who are crazy enough to put images up as their root window on 32 bit deep displays, at 1kX1k resolution). > > Does that memory just disappear as far as the resource handling is > concerned when the client that originated it dies? No, X recovers the memory when a connection dies, unless the client has gone out of its way to arrange to preserve things across connection termination. Few, if any clients do this: it is primarily possible mostly for debugging purposes, that (fortunately, or unfortunately, depending on your opinion) what happens not just vanish before you can see what happened. So the X server does extensive bookkeeping of its memory usage, and retrieves all memory used by clients when they terminate (with the above rare exception). > > What happens with TCP connections? They might be local. Or they might not. > In either case X doesn't know whom to blame. At least on BSD kernels, it was reasonably straightforward to determine if a TCP connection was local: in that case, the code actually did an upcall and delivered data directly to the appropriate socket. Dunno about the insides of Linux. I suspect it should not be hard to find the right process for local connections. Distant connections are, indeed, a challenge. > > 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. Your argument has alot of validity, though the X server does a better job of accounting than you might think. BUT, I'm actually more interested in dealing with scheduling preferences, to get really first rate interactive feel. > > 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. > As I say above, the principle here may be more useful than for the memory example, but for controlling scheduling so we can get great interactive feel. THAT is what is really worth discussing. - Jim -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com - 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/