Received: by 10.192.165.148 with SMTP id m20csp804470imm; Wed, 25 Apr 2018 07:57:51 -0700 (PDT) X-Google-Smtp-Source: AIpwx48t45fIuLj9vlq8mRu3kmNvskqsVG2A+Mmw9I40cJHJ3Io3wnJA52aUXn+ZbRJYxoQQvxl3 X-Received: by 10.99.159.25 with SMTP id g25mr23308343pge.288.1524668271157; Wed, 25 Apr 2018 07:57:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524668271; cv=none; d=google.com; s=arc-20160816; b=mX/8MG82BIJryAULUuUjXODc26iGDaXC5D8B73/nzYji+quy67+SfmG/fUzyjVnryO WBHzeAZtThfkeXw+AWLoI+l4OrOp9LMNSjZ2yjmZRkVLTwI+Cc+9KDpw2rmfPpRdkq3m 4CmSVPyUltsUJP5hl426GsknKk3Tju7xiZ+/fneN7jxIWie/h67mmbHypxycA0zZmrxm dDNhJgzKpYmnEXbM59++/EFaQ8Fd6zNP14ICNBusA7ZQ72VBG3fi70MBUvuIS4H0+nyH 5KZ6PyurwgHFBWD1xjwYHzKh4zE2wG2dvsWgMkzvIgKRqWzK8GDRFYqa52JmH/FucanO N7Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=HdIuHtk9+qd1OsyCW27eo+pjmYK6wsnLKMdReop3UC0=; b=gllD32I6CVsO9cQEeahNFTYdEvpIyDbXOWhBHi5TMI9s0SXFO7hN55tcfozuvQN69i fxYogb8lJ+yzfibXIv7spBhEgWg2qSjIz+Jx7/V+KZefcG73apUKqZ2zZy1XYfaIuUzm 1qwUuWd1ErCh3ka8oRH1hB/DFyiAostkg4y1R6Lj6HNw70XRoLQbKFaNYIGc1kj5a0qA xZR6gHL8s8pw/0Z/dFOY1jWK9NaRQCFmCXsQKkJ7JAzNNQqlhagcDAlRQxFucRSbEpPF iifJP11LzVbx6KRBmkbB/XFoEBjF++mZt7QiEnBK/XYl6wLwcfMRuDRdaj8nela6QFsr IoCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 59-v6si16278137plp.179.2018.04.25.07.57.36; Wed, 25 Apr 2018 07:57:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754575AbeDYOzH (ORCPT + 99 others); Wed, 25 Apr 2018 10:55:07 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:60488 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753632AbeDYOzD (ORCPT ); Wed, 25 Apr 2018 10:55:03 -0400 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w3PEsxv1027892; Wed, 25 Apr 2018 15:54:59 +0100 Date: Wed, 25 Apr 2018 15:54:59 +0100 From: Alan Cox To: Mike Galbraith Cc: Ferry Toth , linux-kernel@vger.kernel.org Subject: Re: DOS by unprivileged user Message-ID: <20180425155459.5a4e40e0@alans-desktop> In-Reply-To: <1524470676.5451.1.camel@gmx.de> References: <9023506.UBh6vynRGa@delfion> <4285098.DEWjdbWF2X@delfion> <1524325275.8078.2.camel@gmx.de> <6057755.ozdVOybsI6@delfion> <1524470676.5451.1.camel@gmx.de> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > I think memory allocation and io waits can't be decoupled from > > scheduling as they are now. > > The scheduler is not decoupled from either, it is intimately involved > in both. However, none of the decision making smarts for either reside > in the scheduler, nor should they. It belongs in both. Classical Unix systems never had this problem because they respond to thrashing by ensuring that all processes consumed CPU and made some progress. Linux handles it by thrashing itself to dealth while BSD always handled it by moving from paging more towards swapping and behaving like a swap bound batch machine. Linux thrashes itself to death, the classic BSD algorithn instead throws fairness out of the window under extreme load to prevent it. It might take a few seconds but at least you will get your prompt back. Alan