Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp4546995ioo; Tue, 31 May 2022 06:51:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQKn7o9I6YANLa45e6NYso3fLhliC+AB04LSB4j2k9lVMgv7jUM3LuA9aUZHPvcjuZjqbC X-Received: by 2002:a17:907:a424:b0:702:f94a:a897 with SMTP id sg36-20020a170907a42400b00702f94aa897mr1997086ejc.255.1654005110147; Tue, 31 May 2022 06:51:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654005110; cv=none; d=google.com; s=arc-20160816; b=XUS/p2tsyKJ45C0crgbpUaKRf85gXrDbMP64DvPMpan2xLi9H1czho5cccW33wvUmS AGqCDy7VbNEt0sMB8u+SVrZCtxsvtbtOx0uppjXmrZWG9Ji+4uPknlmJFtOvT5IfF7Jl yw2BK6x8PBL9/KCP0bVg7xQfSdsCkiwihvprrGv2cEMkuhT2gTbhDeiO398eFLxR7qcu 0bd+PRWAWqxYSJvTmBjxW1tRRpnFwWzYBn+MEkKsvCg8CWjEI4DLDNkzHpo+/k6fXpXt DU7PBMLGrLSmd0UkfQRWY0n5gNoKNwDD1UL5lhn01Ndbwhjd9yIZCURnz6cDZg6hNqNd Y/RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=NJogN3IYLaA0/PYlQIBsunkdnH4gONu4lSZ4HSWPFBg=; b=wSGgdn3E9a4mqcXekX9aiY/G1wvdyAb/Qn5lia+qWGr8GLWHD9NJxhIJuRAZBTkcj7 hjiRxi7HZLbLYkvc7lCPLIvRzwNit5l2Vpk54M3AEZgdG6rTCp6fhgTzXgQEVAxFi7vV vsh0Zarhp4d7PjILbT4+CUBND4YbzJLtM4aNDxkv0+V6Tg6tpzOfgK+Jr/0hQvTofCyn 55GQ6Is8HlhN23PSaxFlBDdHzLSJEkV7O56G89/HefK2ZHHmt/INFnCQyULIlAqCTAVb dRrh3Iu/TRjOQZbDmvjIIkFUTDwJB8CN/0vN9dI0EXtypThpLdyLsR8QGp07LqgJolUe rVUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BXpzd1eU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y12-20020a056402270c00b0042a2dc0745asi10467236edd.34.2022.05.31.06.51.24; Tue, 31 May 2022 06:51:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BXpzd1eU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242741AbiEaBBZ (ORCPT + 99 others); Mon, 30 May 2022 21:01:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238350AbiEaBBY (ORCPT ); Mon, 30 May 2022 21:01:24 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A16C70924; Mon, 30 May 2022 18:01:24 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id t2so3919224pld.4; Mon, 30 May 2022 18:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NJogN3IYLaA0/PYlQIBsunkdnH4gONu4lSZ4HSWPFBg=; b=BXpzd1eUKcwVwUU83YwPDVhBhh3yJZK6vwP+l6BQ0eANXd4G4rGkMYGwVNG58g81TR FRdBloytdVM9FuHTRCYWZxUFPIB+TwxM8AKv+L2jeO/7ul/Hn3QGFAwc/WKRILeAUZcH pRIJUfCJCAzkXBvoWF1EMIwKRQEYNfCCsKCLiZHjLyKgU7eEYXodFIsGN/kDgQ7fVmdJ 4nrdNE7+rMKUSz9p0uajY72fJ0pD9laF02Sq+4yCUL0VoaTaVOHqHh4S72+Py6RwzTFp EsQynD1EBpGZpOHXo2jLWQI70kH5AFlZkJjb6gOisOmAySgftbphAzvyC5JqgI2j78Rb R4FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=NJogN3IYLaA0/PYlQIBsunkdnH4gONu4lSZ4HSWPFBg=; b=p7dEgsVnkczHhzreJO50yL1N2qHKPsuYPHxMmAW/KnVE6qMA7/Cqaf3nEP9Lx0wUmN yUeAU4ETaruey/zyKtg0gtSvWVmb5pSkpVqPP8aIJcGyv9XhFtTzDrX/dGgBmgqDCXix DrMoYIE32VAz45AY9hphfgTdXk+eIGyXp7Ou7JigLLHVuNul5fUj7ErzGZFfdhCA8pZ8 l4p++2m+gbX+1dVJGDJlkys4ZOG497JhsYUpxeezR+nyhSiYdN6t+lYN0YB0Cq5EWKtU LMxyZII9UY4BY1MRBvIJKkKP6+sFt+S7czrMKlZGyaRQKO6SKXwMHSQ8OaKNcH8yJEg9 BlLA== X-Gm-Message-State: AOAM532Y6kyXs+e9vtov6clz5Vgfx3Gyy71v9NFzscnaYF3L+85cf84t MaFHtgcRWX0lEMdN1+/ONFo= X-Received: by 2002:a17:902:704a:b0:161:996e:bf4 with SMTP id h10-20020a170902704a00b00161996e0bf4mr57900290plt.118.1653958883862; Mon, 30 May 2022 18:01:23 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id e23-20020a62ee17000000b0050dc76281e4sm9327678pfi.190.2022.05.30.18.01.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 May 2022 18:01:23 -0700 (PDT) Sender: Tejun Heo Date: Mon, 30 May 2022 15:01:21 -1000 From: Tejun Heo To: Hongchen Zhang Cc: Zefan Li , Johannes Weiner , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cgroup: wait for css offline when rmdir Message-ID: References: <1653619158-27607-1-git-send-email-zhanghongchen@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Mon, May 30, 2022 at 09:53:51AM +0800, Hongchen Zhang wrote: > When I test the LTP's memcg_test_3 testcase at 8 Node server,I get the > -ENOMEM error,which caused by no avaliable idr found in mem_cgroup_idr. > the reason is the use of idr in mem_cgroup_idr is too fast than the free.In > the specific case,the idr is used and freed cyclically,so when we rmdir one > cgroup dir, we can synchronize the idr free through wating for the memcg css > offlined,and then we can use it the next cycle. This is a micro benchmark specific problem and it doesn't make sense to change the overall behavior for this as the suggested change is neither desirable or logical. Maybe you can just incur the delay only after idr allocation fails and then retry? Thanks. -- tejun