Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3546645pxb; Mon, 4 Apr 2022 20:46:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0u5GV0TiOZGrtxxUX8KUN2w2NwCCYqwjZKYK/VhiR/UDsz7i/GEeqcRXuw3z1rvD2wiZF X-Received: by 2002:a65:4185:0:b0:399:4c59:e3b1 with SMTP id a5-20020a654185000000b003994c59e3b1mr1186898pgq.154.1649130376662; Mon, 04 Apr 2022 20:46:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649130376; cv=none; d=google.com; s=arc-20160816; b=xRmyzCzmY2f9xLlithQU/1R90230ZmDngAUoxJ0y4qWKGb6rEqW1c2XZmRpR2H5Tnh 26Wjlr02PdL2wBU+FeZh/jkjl1akX9mj5NoagnrwhxG1t4oEmtJT1GhzmKJypO7VDhBT dDcA4f+HbidoGMv+qiV72CMXA1U9fCNQd8mvIMFqb1RbTF1amzenVt9w5gOMH/1xh4P6 ZwkIjUfQP8/noZXmiZb6YrqFfG+D+hnhpHpQrHWyR3IKS0gwFccHFj7yeW6h+PIi7jlK B6JbbkY8X7O7UWanQ+GnIpAPZyz1z+EyFzzu91FM8CTWe9vNLRdh0a+ILcFZCuuExyc1 6V2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=JTzIzbrqZyK9WcizVERi7qlxh5xxIEK+9IqWImCqDAY=; b=ZL2tG8AwV7Aq0n/AGrXyR6NmaAViifI4G/df2oUlLJbeVdzSQh6F48YxBOS+HAtwpI 5RYQCxA/sE6Lf2X6Unh/zTlQxWDaO34MBz4XvJq9phsQqhzYmd75YgtXJWPTTAobUJAI 7L5i2Z4to9g6TuE5O5uDPpFw8CaOLMI5xRQuEdWPemYzcFKGJNJ2LwIYGFmdQPZHN2Lu ab8RB4uPKHCgQsggTgm0zSeC3h0OFUFRnPvC/asV5oi+1o5HlkY8k+1pHNf2Yv01HftX N6zTSp5W7vm3ANICTFV7FyaZrWUpyApFJ2wfxFpLewmVF5O5zlQoi9iu4sGVSI12rqFy ae3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=YcMVYnQM; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 4-20020a631544000000b003985d5889ffsi11821723pgv.863.2022.04.04.20.46.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 20:46:16 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=YcMVYnQM; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4D5E418B1B; Mon, 4 Apr 2022 19:46:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229866AbiDECsZ (ORCPT + 99 others); Mon, 4 Apr 2022 22:48:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230097AbiDECsL (ORCPT ); Mon, 4 Apr 2022 22:48:11 -0400 Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B31010EDF4 for ; Mon, 4 Apr 2022 19:30:33 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id r2so13580246iod.9 for ; Mon, 04 Apr 2022 19:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JTzIzbrqZyK9WcizVERi7qlxh5xxIEK+9IqWImCqDAY=; b=YcMVYnQMKz2NhQbrK0HjGTOXQmTu+Vk9t1j3Nfgnp7gS4pAl9K8ReC7ZTF3NS0ao62 +k6BganfzYE1RHEvww+e/oOwq6C1n3EDSdgXuZrPrUp/3uVwkyfn+h+4qiNGraccB4KQ nIfDzn7o26dbdKpb851QTXPT7ZhljzDSnSko5y404+cDtwPiIHYDokLbazUURxbzDJYf 0wCUTDsNI802WAuIUoPq6xTRWniX7nxbPjm5nqHr5UFiVd2OkMiVpH3V//O4UytUclaa R0jpdX1UgmZmW10eiTYtRmFvTG/l/HJtjLd+9wWEiVF0naJ4VQ9kG+1P5NjKQrF+efCb Vk2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JTzIzbrqZyK9WcizVERi7qlxh5xxIEK+9IqWImCqDAY=; b=gtbOLAwHUQka9GLXwnOhswGA8W2ojY0+R8aIf+TgNK8/X4ymstvgGWFjAVTTMGYa6T zyb/yxhsCUQhRNgfMv7XMi1s4cGfOmi/GRAyIH6evK3X0rLVGXBAzKQRojZUBps8Xfqy FtGioB/zOGUC/n3Z4swmo04YFLddS5oOYS0MstTpYzs9lZ9BGyNGu0pZuev0WNiCbigP 3D+iRd2V8edeDH1EXZ0Ju8cpRaCH4b0r9bEi69BVhvTzzvwd2LRVMPMQI0Q3gOW0feA8 h36tASCIyJmU9v4yXnHNMUHOeBgl+VNMo0PNb2dgmWEoPk5fVvfQ7U3HQ3tE4vnYTAf6 eIPg== X-Gm-Message-State: AOAM533FHwbtUEkUXA2SndxNvllANUtlAw5HbtXdy+z2KpgM8pUczkCN HGO6NEwFA56EA6Mk3XjXt4zSkgmNrSyyBnyvFfbgqA== X-Received: by 2002:a02:84c9:0:b0:31a:1cf2:4468 with SMTP id f67-20020a0284c9000000b0031a1cf24468mr806877jai.31.1649125832511; Mon, 04 Apr 2022 19:30:32 -0700 (PDT) MIME-Version: 1.0 References: <20220331084151.2600229-1-yosryahmed@google.com> In-Reply-To: From: Wei Xu Date: Mon, 4 Apr 2022 19:30:21 -0700 Message-ID: Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface To: Shakeel Butt Cc: Johannes Weiner , Yosry Ahmed , Michal Hocko , Andrew Morton , David Rientjes , Tejun Heo , Zefan Li , Roman Gushchin , Cgroups , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Linux MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL 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 On Mon, Apr 4, 2022 at 10:08 AM Shakeel Butt wrote: > > On Fri, Apr 1, 2022 at 1:14 PM Wei Xu wrote: > > > [...] > > > > -EAGAIN sounds good, too. Given that the userspace requests to > > reclaim a specified number of bytes, I think it is generally better to > > tell the userspace whether the request has been successfully > > fulfilled. Ideally, it would be even better to return how many bytes > > that have been reclaimed, though that is not easy to do through the > > cgroup interface. > > What would be the challenge on returning the number of bytes reclaimed > through cgroup interface? write() syscall is used to write the command into memory.reclaim, which should return either the number of command bytes written or -1 (errno is set to indicate the actual error). I think we should not return the number of bytes reclaimed through write(). A new sys_reclaim() is better in this regard because we can define its return value, though it would need a cgroup argument, which is not commonly defined for syscalls.