From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Indentation and gc Date: Wed, 15 Mar 2023 14:54:29 +0200 Message-ID: <83zg8eqinu.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <87ttys4dge.fsf@web.de> <83sfebyepp.fsf@gnu.org> <87ttyru4zt.fsf@web.de> <83fsabyb41.fsf@gnu.org> <87mt4jtpqf.fsf@web.de> <83ilf7wi48.fsf@gnu.org> <878rg3wh2f.fsf@localhost> <83cz5fwggd.fsf@gnu.org> <871qlvwg1s.fsf@localhost> <83a60jwf9l.fsf@gnu.org> <871qluuk3y.fsf@localhost> <831qluuj7e.fsf@gnu.org> <87v8j6t3i9.fsf@localhost> <83v8j6t2ib.fsf@gnu.org> <87zg8gbsch.fsf@localhost> <838rg0u0fd.fsf@gnu.org> <87wn3ky7rz.fsf@localhost> <831qlstwoi.fsf@gnu.org> <87r0tsy1c4.fsf@localhost> <83wn3jseyt.fsf@gnu.org> <87mt4eqpfd.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34673"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 15 13:55:24 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pcQf5-0008nz-I4 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Mar 2023 13:55:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pcQeL-0005IN-Od; Wed, 15 Mar 2023 08:54:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcQeJ-0005FB-Gx for emacs-devel@gnu.org; Wed, 15 Mar 2023 08:54:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcQeI-0003pr-JX; Wed, 15 Mar 2023 08:54:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=//w5Ea9yi37gayJLJIDfQse8/bnP7+jnOuZTYeK3+TY=; b=hPb2i3SuaKL3 fl5dSBy2LUUMwtk1aTvRGgQhzfypaCjk22ka3VgEREdEbzhrq0MrDIckyxS159PTdJphgESkrdV71 6o3AzLT5X7zYKGE42P7+3SjNrnaxgopj0vqOrKhfEoUuCUOtIrG8TiKgh9JAhrv0p70OR+rN64WUx 5LyHHp9z6hUNGV5sjd3U2hL1UYIzY9+e+1PNRlZdV0vPNnKNy4t8cZ7FPvFqL4Y26PDVoIa0BXUbS rismMnH5sj9bpTndck/FY0uF6w97r+B9PxghYJ/xV/IukP2ogbiHibYFnTy4BHBunvrrSR5G8l5JI 9hhLZjJV7p7W0byJad1SmA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcQeI-0005nC-3C; Wed, 15 Mar 2023 08:54:34 -0400 In-Reply-To: <87mt4eqpfd.fsf@localhost> (message from Ihor Radchenko on Wed, 15 Mar 2023 10:28:22 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304494 Archived-At: > From: Ihor Radchenko > Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org > Date: Wed, 15 Mar 2023 10:28:22 +0000 > > Eli Zaretskii writes: > > >> Moreover, VIRT can exceed Memory + Swap combined. > > > > Yes, because VIRT includes the "reserved" memory, which is memory not > > yet in-use, but which the application "reserved" for itself and > > generally intends to use at some point, and so it cannot be used by > > other processes. See > > > > https://stackoverflow.com/questions/2440434/whats-the-difference-between-reserved-and-committed-memory > > https://www.baeldung.com/linux/resident-set-vs-virtual-memory-size > > Then, from what I can read, it does not look like VIRT truly represents > how much memory Emacs is going to use. It is safe to assume that only a > fraction of VIRT will be used in practice. I don't think I follow your logic. Emacs can have more memory in use than the physically installed amount, it just means each GC will be painfully slow, because it will need to swap in parts of memory and swap out other parts. In theory, Emacs can use all the VM there is, minus what other processes and the OS use. If your bother is about the "reserved" part, that is not supposed to be large, but maybe glibc has its own ideas about that, because your report about VIRT vs RES surprised me.