From owner-freebsd-questions@freebsd.org Sun Jun 3 22:51:06 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BC65FE86DB for ; Sun, 3 Jun 2018 22:51:06 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B94482150 for ; Sun, 3 Jun 2018 22:51:06 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm0-x244.google.com with SMTP id v131-v6so11331758wma.1 for ; Sun, 03 Jun 2018 15:51:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0D8ZVsxwt2FxgtMLPLmo7PTLmBqfP8G7J3QjP+rIGck=; b=oXb4iZlknRqrSj6IAPP2eq4KwKTV9QVuTsd8Pzdk8mpXj1bBUrxpp0lZE3W4DmID/7 4VFAi54NbKh+i0cXs8uqsjeH5aBL9WTc+iUkx6dVoKyqDEUgFdSBUMWh4edlEAbcu1VU 2v1yIsod1b/nVY4na/jVm/Xd1Zhq224KB/MaF5uqD0O0t+GR82RoVfafmsbA32YfiLF2 aEuUslzrPI5DEALzgdKTkW26g2+aFUAQ+AlvilPcxVvTTcWiHQOijw9W05PAYzzaMp2p DodeVrFFJMD/GhcAygqhKKaJJ0tC1p5nK7uHKwtEWU6NhdLsaexpVs1P1XxPuJsgv3u0 EM9w== X-Gm-Message-State: APt69E2nEQjTgRxa7S0L0l4M5uQYPGpPFesowV607e57o8swMEPrfk39 FBfnxgQ15sPoMhD8UBcK53+2TA== X-Google-Smtp-Source: ADUXVKINvFJIAJ9VwdiLK9uaOWJTFA9rGjzuzQfDHKJ6akkibPmh/fV+R4eU7NYR9BBpgGM7Ff4qBg== X-Received: by 2002:a1c:4056:: with SMTP id n83-v6mr8046606wma.6.1528066264726; Sun, 03 Jun 2018 15:51:04 -0700 (PDT) Received: from gumby.homeunix.com ([90.211.23.147]) by smtp.gmail.com with ESMTPSA id j9-v6sm6762984wmh.28.2018.06.03.15.51.03 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 03 Jun 2018 15:51:03 -0700 (PDT) Date: Sun, 3 Jun 2018 23:51:02 +0100 From: RW To: freebsd-questions@freebsd.org Subject: Re: Is it normal that a user can take down the whole system by using too much memory? Message-ID: <20180603235102.570ebd1b@gumby.homeunix.com> In-Reply-To: <20180603210915.7da21bf1.freebsd@edvax.de> References: <1527977770.2651378.1394286400.0806CC5C@webmail.messagingengine.com> <01EE7EEA-03AC-4D71-BA08-B0CEA97EE720@thehowies.com> <1527981931.2670335.1394316280.09410FC9@webmail.messagingengine.com> <20180603210915.7da21bf1.freebsd@edvax.de> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 22:51:06 -0000 On Sun, 3 Jun 2018 21:09:15 +0200 Polytropon wrote: > On Sat, 02 Jun 2018 19:25:31 -0400, Brennan Vincent wrote: > > I'm also curious, however, to learn more from an OS design > > perspective. Why isn't it possible for the kernel to realize it > > should kill `eatmem` rather than make the system unusable? > > > > Is this a hard problem in general, or just a missing feature in > > FreeBSD specifically ? > Resource control mechanisms are present in FreeBSD, but it takes > a system administrator with sufficient knowledge and experience > to decide about the values that will apply - how much RAM can be > consumed, how many child processes can be spawned, how many files > can be held open... and so on. There just is no system default > that can be preconfigured, calculated, assumed, guessed, or > arbitrarily chosen. No "one size fits all" solution is possible. Configuration isn't relevant to the question as it's just a way to avoid reproducing the test conditions. > Just take the following example:... > For this example, try to imagine at what stage the kernel should > interfere. And _should_ it interfere? From the practical point > of view, everything worked as it was intended and expected. The OP's program is attempting to dirty many more pages than will fit in swap+ram. Eventually, as a last resort, the kernel has no alternative but to start killing processes. The last time I looked it did kill them largest first which has the best chance of killing a runaway process first. When I ran a similar test a few years ago my program would get killed as expected, large amounts of swap and memory would be freed and the system would return quickly to normal. The issue here is that the OP is only seeing this behaviour half the time.