Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5088037pxv; Wed, 28 Jul 2021 02:48:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzprX4Gi4mmp3WN3Qme1B3SOjIWx2m+cMz/on2/YBr5VUR+GyGZGIXHUwBz1DNR6Uaiaf/X X-Received: by 2002:a92:7a12:: with SMTP id v18mr19496704ilc.27.1627465701903; Wed, 28 Jul 2021 02:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627465701; cv=none; d=google.com; s=arc-20160816; b=YUUBs8AA5TrGVv5DMNpJTv8mvCqBJ8feaW6Z3iG6YeOsHxq02Vm5gj018jCUnYff3f ugYAj71Q6FmEygo1ho/MoMNUWrGC4oeD/jCE+D6x+gU4Dl71GDhrYsh6hIVw7MPWQqQR mVxL43n4sTakflooGgXFOf4EWH3y/Q0Jy1E6RTUXfFah/PXVJ+pCpmyvg2JsCXssS5IK WBcdJ0PwfGg7He88IMgrKYsPGISLeMBH/z8us0bWsH1dgFcn3cTfFHm6Ilwc4iho/YCR jqUt/zRIgrY/bXsRtSmlbaWAW9uYiHJYoTwFoNOmfZrpoN/q5zrAdYob/M5ol5G4YOoy azkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=iPJfT32PGYt4NJ5C+bncE2oPEQUqDqGzmN3ZvuFQkGI=; b=HYP8lvOKAC0BP8wrjVQfnBAhAH1PnLy4PNh337YG+PsvojAMWqxFcdyoasgtFfY8iS nR0yUS/I0vKYiCDEYNcGnBBc5UjifONJN9k2s6z5Y03ZPAH0mPg3uBuObFeWm2q6tP+w EAD39Cn+HXtoFtpWf1npJVr8tVYxNuYX55IZ0eSd3KidDcpa6LNaoMmP9byIg9WLYxEG vl69CKwf7YVjXuL/5Gxn1Pv7pRhY3rmaNTr656X0JTyIL7vJEtVF8ExGWAii+ed5Ti/O 6+xO3jgCkoMLfZKbWOUcBN3xWF6rbfXyKXLl6g5TZJBZSvMfhOfbuJwdItTjzpkOj02d 3dUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SV1ILPTp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t10si6575645jal.117.2021.07.28.02.48.10; Wed, 28 Jul 2021 02:48:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SV1ILPTp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235727AbhG1JrP (ORCPT + 99 others); Wed, 28 Jul 2021 05:47:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235012AbhG1JrO (ORCPT ); Wed, 28 Jul 2021 05:47:14 -0400 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8385C061757; Wed, 28 Jul 2021 02:47:13 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id n10so2001288plf.4; Wed, 28 Jul 2021 02:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iPJfT32PGYt4NJ5C+bncE2oPEQUqDqGzmN3ZvuFQkGI=; b=SV1ILPTpHhcPVfAExOd1xUWdXjac03q3/bUhkyQX0fBdxe9DOlGsmMoBR41c+6BGS1 Y0sIHvQZNNT2c8Zp/bCNbM/cakRjXXnx1hlcCRQ0sgtG60ew5BVyr0t+HdLCOg5F0q0u 0BdYBhUh5aZ8EC8VgZv9MHym0Qr3Xuw3B6L/77nDLHMm4E0g09Lmvp60n6z+Xk2WXYd+ PN+Ba6UTM+l6IIjaRK23rgFWjpBGZNDAThaEjTU0ZUhjESHHWrgL0h8QL/SBrvkHRac8 k56RLfEk5+7t0OBQpM9yDL86L4/+8Cxt8jgkfTPPakD9A31e/UrdMnwMEOBz+csXj9HI 5d6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iPJfT32PGYt4NJ5C+bncE2oPEQUqDqGzmN3ZvuFQkGI=; b=TGZZEpG3GqxjtjoyX7Q9HYVwz43KkHFRDunAY+9C+ND58OoVkekEmvZ10CVR6tCMcY POFEFK00STNQGNsf621VaktkSqToLhKx5TSZNyZ1IG79wZeSC+2P15Oj1riZ83hHtsmC spyVFDyzVhblwVaAmyxig+DNtlzOjI8i+GwFYvYyZib51/2jgFUhE1cBDFyMvf+crOAu 9v6Sc0ZWIs+nNqiIOR47QorIAG6fC0g75O54oQUkOxXGm6MqK7E3ei9TWfZKE9jTmT1i eDyQocM5mvQBbDzFvzNKCv3/V3JZn8rHHbN+Tz8olJNdxsZL8qc0CI3Py+9ApnPuqELJ qUpQ== X-Gm-Message-State: AOAM532VnWvrSmzYqhrg3a9hJcupGsT72gqJbtqmqoiDqGohiCgm2/V6 yZOo+Ax9ij9eN19hHznQ8YEeCy0RA9n5jJRs X-Received: by 2002:aa7:9e1b:0:b029:384:1d00:738 with SMTP id y27-20020aa79e1b0000b02903841d000738mr23528820pfq.71.1627465633057; Wed, 28 Jul 2021 02:47:13 -0700 (PDT) Received: from [192.168.255.10] ([203.205.141.110]) by smtp.gmail.com with ESMTPSA id r18sm7495964pgk.54.2021.07.28.02.47.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 02:47:12 -0700 (PDT) Subject: Re: [RFC PATCH v2 1/3] misc_cgroup: add support for nofile limit To: Tejun Heo Cc: viro@zeniv.linux.org.uk, lizefan.x@bytedance.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org References: <3fd94563b4949ffbfe10e7d18ac1df3852b103a6.1626966339.git.brookxu@tencent.com> From: brookxu Message-ID: Date: Wed, 28 Jul 2021 17:47:05 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tejun Heo wrote on 2021/7/28 3:41 下午: > On Wed, Jul 28, 2021 at 11:17:08AM +0800, brookxu wrote: >> Yeah we can adjust file-max through sysctl, but in many cases we adjust it according >> to the actual load of the machine, not for abnormal tasks. Another problem is that in >> practical applications, kmem_limit will cause some minor problems. In many cases, >> kmem_limit is disabled. Limit_in_bytes mainly counts user pages and pagecache, which >> may cause files_cache to be out of control. In this case, if file-max is set to MAX, >> we may have a risk in the abnormal scene, which prevents us from recovering from the >> abnormal scene. Maybe I missed something. > > Kmem control is always on in cgroup2 and has been in wide production use for > years now. If there are problems with it, we need to fix them. That really > doesn't justify adding another feature. But considering stability issues(k8s), There are still many production environments use cgroup v1 without kmem. If kmem is enabled, due to the relatively large granularity of kmem, this feature can also prevent the abnormal open behavior from making the entire container unavailable? but I currently do not have this scenario. Thanks for your time. > Thanks. >