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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8AFDC433F5 for ; Tue, 5 Apr 2022 02:30:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C3126B0071; Mon, 4 Apr 2022 22:30:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 372DC6B0073; Mon, 4 Apr 2022 22:30:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 213276B0074; Mon, 4 Apr 2022 22:30:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 11E576B0071 for ; Mon, 4 Apr 2022 22:30:44 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D0C9C2046D for ; Tue, 5 Apr 2022 02:30:33 +0000 (UTC) X-FDA: 79321246746.08.ED9A1E5 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by imf09.hostedemail.com (Postfix) with ESMTP id 5AAA4140035 for ; Tue, 5 Apr 2022 02:30:33 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id x4so13606424iop.7 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=WLN9zWLVBF0hfwEZI+a7u4tucEJ6O+RudzDiJNx6/YEpV7KAKIE/lIf/5H5QACEVT1 QWHGbu8a+TxchVOBiilJb9t8uFGc7ud4qmva1dcZuTpKUDnGknPtxwEbdC1dr2FAoYjB mcufwZvOOBarE8eu0m97+qmIlrGTceAptYlRk8Z/DdICmngjvvm690QnETNUkntyDgot wMIA0wDRuBjeh5nuLk7WlxRLSobyXPUOh/T7tQRdf5tW0SUe8vU4TiDECc2FHJqjhkEC oLpebjZDGGhJ3YDb7D9buKuV4it6/mAIL7M7fdAm3koZr02KmXRs8pASQ1E0rd3y4SxK /NAg== X-Gm-Message-State: AOAM5322PW3yeKQl0Qq7fM7n35cfKk4Lo+SZJgaUT02ZSA9ah2oTaizv HhAyFxY9vJViTGX3+2TSwWEXYatxnVNhGZ37RDcBTg== X-Google-Smtp-Source: ABdhPJwODLum9ilGhChVng+UBA9UPlj2zbdInzRba3Olr4b4wDij4kupJU4FIgzVrCfK1I45tTbjXWS8CK+5nB/27Fs= 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" Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=YcMVYnQM; spf=pass (imf09.hostedemail.com: domain of weixugc@google.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=weixugc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 5AAA4140035 X-Stat-Signature: 6wng4xms3995t1mxptoai996t1rdc6bx X-HE-Tag: 1649125833-20181 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 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.