Received: by 10.213.65.68 with SMTP id h4csp2643700imn; Mon, 9 Apr 2018 06:53:36 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/VfhrlhuM8LTh0HK8m+d3GZY7E8EXu68vCyZxlnuKLEv3/ByX2VTqUxesSqWv7Dif/pypB X-Received: by 2002:a17:902:2c83:: with SMTP id n3-v6mr39637451plb.317.1523282016751; Mon, 09 Apr 2018 06:53:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523282016; cv=none; d=google.com; s=arc-20160816; b=pciactPUKRpWCBOZlw5dU+OFXtUCwJlT+0GBqucauCzVmioHleljS/oywa7hGnlIir hekg0t2gRNQFjgWNQfSujZIuPUqCQXoLmvHYWKMoyk3QzYE+ZC9UtGmpg0RcphcEABD4 KBMoMmDmCttFvKZn/OFuCwmBJT3ndtTJlgcwPx7UuBXVfMjQCAJcCQRMaeXKlRPgb9qL 3DUg8Q0dglZGK0btzWkyVY84j7p97pUdj8hpNYJwTFLn94zPZOF9leWO9nkW7TbTJpw9 m9GrPrdw6ULSqQqja8LqAS/9ba0vhWMV9qTr84M9CTLnooTJMrKQ84OwNSXyj61/Sl8L 1ybg== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=KKUd3FGw0Jl8KtaOmLInipNDRVWZEpwU5lEv8+ks5wQ=; b=X3nczZLRAiLj9eNY2cPfEbZO6DRvPjbPit//byT8byP5LVkQQlz9GyT/6NEfWUegXe KZQikjWTlzQekZe/RLPTbsY3m/dq/MNaM0/qlHHRAtrNJw2W+qOvblhKOE966Lr52IxK 5sBn1nzV6SNEx5SvEkP/Qwu3cFdtP09ZqKeLkmACuWfuQLV4/fvylhj3caW8WVtjnOPx Zph7RwmJAU4S+CfAMtRU/wmTTN0rTj7IriXh6rcxJDSgh/MBr7CvT+3lsVDVOGVP6NDG RuC7eg5IDAnDs6OrouNvhWnmFJabwHZugd3YR6WyQbA9JpEz6yymalT2+ERTRtDhcE0G MiCg== 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 x8si296034pfh.245.2018.04.09.06.52.58; Mon, 09 Apr 2018 06:53:36 -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 S1751548AbeDINtt (ORCPT + 99 others); Mon, 9 Apr 2018 09:49:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:57266 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750759AbeDINts (ORCPT ); Mon, 9 Apr 2018 09:49:48 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EAD6A20838; Mon, 9 Apr 2018 13:49:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EAD6A20838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Mon, 9 Apr 2018 09:49:44 -0400 From: Steven Rostedt To: Zhaoyang Huang Cc: Ingo Molnar , LKML Subject: Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN Message-ID: <20180409094944.6399b211@gandalf.local.home> In-Reply-To: References: <1523153783-20579-1-git-send-email-zhaoyang.huang@spreadtrum.com> <20180407234812.2bf2b24b@gandalf.local.home> <20180408084717.62ee4f9e@gandalf.local.home> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-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 On Mon, 9 Apr 2018 08:56:01 +0800 Zhaoyang Huang wrote: > >> > >> if (oom_task_origin(task)) { > >> points = ULONG_MAX; > >> goto select; > >> } > >> > >> points = oom_badness(task, NULL, oc->nodemask, oc->totalpages); > >> if (!points || points < oc->chosen_points) > >> goto next; > > > > And what's wrong with that? > > > > -- Steve > I think the original thought of OOM is the flag 'OOM_SCORE_ADJ_MIN' is > most likely to be set by process himself via accessing the proc file, > if it does so, OOM can select it as the victim. except, it is > reluctant to choose the critical process to be killed, so I suggest > not to set such heavy flag as OOM_SCORE_ADJ_MIN on behalf of -1000 > process. Really, I don't think tasks that are setting OOM_CORE_ADJ_MIN should be allocating a lot of memory in the kernel (via ring buffer). It sounds like a good way to wreck havoc on the system. It's basically saying, "I'm going to take up all memory, but don't kill me, just kill some random user on the system". -- Steve