From owner-freebsd-questions@freebsd.org Mon Jul 27 00:09:29 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7ED0C3709DC for ; Mon, 27 Jul 2020 00:09:29 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BFKtH5r34z4F0S for ; Mon, 27 Jul 2020 00:09:27 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.5.224.215]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPA (Nemesis) id 1M4skB-1jyTWn2GJz-001yJo; Mon, 27 Jul 2020 02:09:22 +0200 Date: Mon, 27 Jul 2020 02:09:21 +0200 From: Polytropon To: "Steve O'Hara-Smith" Cc: Valeri Galtsev , freebsd-questions@freebsd.org Subject: Re: Ask stupid questions and you'll get a stupid answers, was: Technological advantages over Linux Message-Id: <20200727020921.92e951f7.freebsd@edvax.de> In-Reply-To: <20200726213915.00772928e53bd4105872ee71@sohara.org> References: <20200725152412.GJ92589@admin.sibptus.ru> <20200725162403.GA4721@admin.sibptus.ru> <20200725182554.deffc63058a7c9f6d343ef06@sohara.org> <04df312d-9b2b-1873-2117-79a49e089bd9@kicp.uchicago.edu> <20200726063256.GA22924@admin.sibptus.ru> <20200726093909.ee5e14e643d31da4dad5c804@sohara.org> <20200726151835.GA35966@admin.sibptus.ru> <27ca8c6c-6b06-6ad4-7af0-2b88f51a3856@kicp.uchicago.edu> <20200726165212.a0ac28ce104b9dfd009cc4c5@sohara.org> <7290c25a-aaf3-b864-0ed8-ec9558777681@kicp.uchicago.edu> <20200726213915.00772928e53bd4105872ee71@sohara.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:oPNSiyw8g8A5dc/yf2EIWbaIbE+YX4XEZH7Z30xA70jhZmWFEhY QEy7gSbOMXhwTwcElrphMR8C+NuJv8CLzlkLlN+6xvXG/NVmqceB4wYckyHf34ViqM1HfF2 0tlYMFEdukY1FzV21YcxGn90iTRZJ3eUCKRPr0KgeWpb22+zmYUgBDLNOekWfWooSeMA1H3 GDopvicR8Z5Zu3i8p/Enw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:QuO9BzjmuLk=:zlanIxEebSddQMfAvy6LcW rfUxXm+c7fBNRJi+9kF+mfPxmXQL74r5D9KAoU/n26I0zfld8aZiMNOPvo9ALg7PAPorP9177 35h6Oh2JEp8dqTyWcnH2SGAykuQgzjRzLDjeTaSnPIgqvgu6uF0jr4F4G44+NXBjHg7/Kzdb2 C3Q3HjYzHOzULbwoErBslSb3z3jFbYaN1oZJ46Lwoht6hudZfRiUzLLs+WLU9PsfS6jq5r/2P sXfTqqd+xd76De9edLGItEARRSFEObuUHnv5eJZ51aOToNqO4jhRVsmnvaXUZygw3mv2xy+jq VZrVAMcvgrmWzD1u5Dw+3Nng68ItkGbr9TOZW7F1OLwR4r4kV+iNeGu0xsrX/H6nEklXuJJx4 ZTB8ST9PSQcq88B92HNR4qdLg+Tr6wn+azRPKvHXcOfRKeBIuZBazrveoiCoaeuaU07RsrdN4 F/YHJO3kt+CJque7ACti7lydKI+CrwzUuyNXaPsoumUcXDb8ogtrqumy5Y290kr3aWAzsPBSN CEB21oxNBIiefnChDPuojNZyZ5ziSjg5rgIEYT1mVBPBasE1z6bmUy002fTfCkCJtfOVJOT/D 5bv37esdSZPBTp6ffiw1GZHBNvFg4sfSpTjCX/x9jtrJR1KL3t9PC3rtDE974hCU1CP8ETgEy CMgh8Kxu2vf8lD6TyYQb5miRER5+WteqFjT4CbaKtC+NeXzPqdcPNapDNsc0LO+SOtnNT8Wko aAnVjRHorqgb+c3umOO47AQAQ/JIQTGtGbPClXkB4GshxPrSuftoqXOW35+5YRm22/DSRQ+HS kAEZPMJ5ZfyVaGFabCM+v9llFDGV303w4Y/MAgEB5XnaTStdtvoC5SmXRUB/v/ZD6nQcpQX X-Rspamd-Queue-Id: 4BFKtH5r34z4F0S X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.135) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [3.72 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[178.5.224.215:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.17)[-0.166]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.77)[0.772]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.72)[0.717]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.227.126.135:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.126.135:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 00:09:29 -0000 On Sun, 26 Jul 2020 21:39:15 +0100, Steve O'Hara-Smith wrote: > On Sun, 26 Jul 2020 10:56:16 -0500 > Valeri Galtsev wrote: > > > > > > > On 7/26/20 10:52 AM, Steve O'Hara-Smith wrote: > > > On Sun, 26 Jul 2020 10:39:16 -0500 > > > Valeri Galtsev wrote: > > > > > >> My understanding of Linux OOM killer lies along same lines though my > > >> understanding is much more simplified: kill minimal number of processes > > >> to recover maximum amount of resources. > > > > > > Not always the right thing to do though. > > > > > >> Another speculative way to say > > >> it would be: process owning maximum amount of RAM that keeps allocating > > >> more RAM is first candidate. > > > > > > What a pity if that is the heavy weight analytic program that > > > has a run time of several hours/days and is the only thing that matters > > > running on the system. > > > > > > > And yes, I agreed with your sentiments (or judgement): killing a process > > is a bad thing always. Agreed before writing any of my comments. > > The trouble is there really isn't anything else the OS can do > because nobody ever thought to implement SIG_RELEASE_SOME_MEMORY_PLEASE > which would probably be the ideal solution provided at least *some* > programs responded to it. As you mentioned, it depends on the problem programs ("apps") to actually receive and act upon such a signal. "We don't need to care for SIGMEM, because if _we_ need memore, we _need_ it, and the fscking OS should pay attention to us and give us all that memory!" ;-) > Which leaves the only variable how to choose which process to kill > and there are no general rules for a good choice. The OS cannot guess what programs the user is interested in keeping at a certain time, and what programs it could stop to free resources, neither can it predict how programs will react when some processes are killed from within a call hierarchy. "If a subtask is killed, re-instantiate the task, but allocate twice the memory it had before!" ;-) So we're currently living with what is technically possible, not with what we desire to happen... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...