From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3900C433E1 for ; Mon, 17 Aug 2020 15:38:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8A5FD22C9F for ; Mon, 17 Aug 2020 15:38:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PCDaGtJ/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8A5FD22C9F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2CD2C6B0022; Mon, 17 Aug 2020 11:38:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2575C8D0003; Mon, 17 Aug 2020 11:38:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 146D86B0024; Mon, 17 Aug 2020 11:38:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id F1ED26B0022 for ; Mon, 17 Aug 2020 11:38:56 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A469D12ED for ; Mon, 17 Aug 2020 15:38:56 +0000 (UTC) X-FDA: 77160468672.10.year37_6005c7b27017 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 6EA3916A4AA for ; Mon, 17 Aug 2020 15:38:56 +0000 (UTC) X-HE-Tag: year37_6005c7b27017 X-Filterd-Recvd-Size: 4559 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 17 Aug 2020 15:38:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597678734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZkWVLRXZ5vVFgxHkOqqYvCoNjff7Y5hvG4el3ZRbhHA=; b=PCDaGtJ/hYwQosgCRiZvDPtF2KD4EwEYW+2PzBs1Q8bPSbI+xoqq5wfL5tD5FMIwUO600G 2Hi3U4T6N9RXRMp6DUhLqy+GeAZZ1H77qpDkqQj72hdTlOdOZjnx766ggofFtJdNmWSakE a3y70DhJCknHgmLV+i4P5Nde5wE78uA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-500-RxczTlPaMrKBj81he1F3KQ-1; Mon, 17 Aug 2020 11:38:52 -0400 X-MC-Unique: RxczTlPaMrKBj81he1F3KQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D38AF807333; Mon, 17 Aug 2020 15:38:50 +0000 (UTC) Received: from llong.remote.csb (ovpn-118-35.rdu2.redhat.com [10.10.118.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4F98A614F9; Mon, 17 Aug 2020 15:38:46 +0000 (UTC) Subject: Re: [RFC PATCH 1/8] memcg: Enable fine-grained control of over memory.high action To: Chris Down Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , Jonathan Corbet , Alexey Dobriyan , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org References: <20200817140831.30260-1-longman@redhat.com> <20200817140831.30260-2-longman@redhat.com> <20200817143044.GA1987@chrisdown.name> From: Waiman Long Organization: Red Hat Message-ID: <934e4bc3-bab6-b19a-49f9-6a6ae8638570@redhat.com> Date: Mon, 17 Aug 2020 11:38:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200817143044.GA1987@chrisdown.name> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Rspamd-Queue-Id: 6EA3916A4AA X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 8/17/20 10:30 AM, Chris Down wrote: > Astractly, I think this really overcomplicates the API a lot. If these=20 > are truly generally useful (and I think that remains to be=20 > demonstrated), they should be additions to the existing API, rather=20 > than a sidestep with prctl. This patchset is derived from customer requests. With existing API, I=20 suppose you mean the memory cgroup API. Right? The reason to use prctl()=20 is that there are users out there who want some kind of per-process=20 control instead of for a whole group of processes unless the users try=20 to create one cgroup per process which is not very efficient. > > I also worry about some other more concrete things: > > 1. Doesn't this allow unprivileged applications to potentially bypass=20 > =C2=A0=C2=A0 memory.high constraints set by a system administrator? The memory.high constraint is for triggering memory reclaim. The new=20 mitigation actions introduced by this patchset will only be applied if=20 memory reclaim alone fails to limit the physical memory consumption. The=20 current memory cgroup memory reclaim code will not be affected by this=20 patchset. > 2. What's the purpose of PR_MEMACT_KILL, compared to memory.max? A user can use this to specify which processes are less important and=20 can be sacrificed first instead of the other more important ones in case=20 they are really in a OOM situation. IOW, users can specify the order=20 where OOM kills can happen. > 3. Why add this entirely separate signal delivery path when we already=20 > have eventfd/poll/inotify support, which makes a lot more sense for=20 > modern =C2=A0=C2=A0 applications? Good question, I will look further into this to see if it can be=20 applicable in this case. Cheers, Longman