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 5F52EC25B4E for ; Tue, 24 Jan 2023 15:00:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF4AA6B0072; Tue, 24 Jan 2023 10:00:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7DC46B0075; Tue, 24 Jan 2023 10:00:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF8006B0081; Tue, 24 Jan 2023 10:00:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BB7E36B0072 for ; Tue, 24 Jan 2023 10:00:03 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8EE841405EF for ; Tue, 24 Jan 2023 15:00:03 +0000 (UTC) X-FDA: 80390002686.21.D54FFA6 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf26.hostedemail.com (Postfix) with ESMTP id 6023714000E for ; Tue, 24 Jan 2023 15:00:01 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ioVsAhbB; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674572401; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XLqxBQfQ00tnQcihjlqxyWWIteOiPhmeVkN+U5n5QiU=; b=6PjShjfPYNoCZnOoWSu4Uit9/8IwAFag1NJCzm5+Fj0JhfWi2TJryikoUyaqDIrW8ZC8eX zzz0yZqlUWxYyt3RYkNcCeQmymEiCxDPE4maFQQJVF+rIXMR+p894uDO2AUSPmxhzNajn/ M6UdsuE5Rey5aTDBacLkjzs8BKUofxE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ioVsAhbB; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674572401; a=rsa-sha256; cv=none; b=5xR9XHS5mQrVuBoSC7h94QdZGIB1CCKvjuNVa7vCWnE3rmWZXVo2No53OFT1XwFGauDT0I M22VaZV5qqreQWRgXfT8zGS0GfrkERMV0VkxKaWfn+DA+NH2TxXxbrmjeZDi5/jEd6Ugib 95PRohh4cgiIeSTtMQwir3NJ6NIxUrk= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B6431210E7; Tue, 24 Jan 2023 14:59:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1674572399; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XLqxBQfQ00tnQcihjlqxyWWIteOiPhmeVkN+U5n5QiU=; b=ioVsAhbBdV1YHrLBEs6yIdAAV1QXNCZMBuzPaF312N9LCK2343XbyDbjM+FY8t1ZkxHq4n Oiz2oPGK3yovgBjLtnfOF0kKVLRWhKt1RSD2ksahTFWRZVbES3/JrtXujjXbbOKWjgqA2O iC2w/WyjLdNarJQAiedANs3mQbkKCFc= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8DC75139FB; Tue, 24 Jan 2023 14:59:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ScUvIm/yz2PoFgAAMHmgww (envelope-from ); Tue, 24 Jan 2023 14:59:59 +0000 Date: Tue, 24 Jan 2023 15:59:58 +0100 From: Michal Hocko To: "T.J. Mercier" Cc: Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , daniel.vetter@ffwll.ch, android-mm@google.com, jstultz@google.com, jeffv@google.com, cmllamas@google.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org Subject: Re: [PATCH v2 1/4] memcg: Track exported dma-buffers Message-ID: References: <20230123191728.2928839-1-tjmercier@google.com> <20230123191728.2928839-2-tjmercier@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230123191728.2928839-2-tjmercier@google.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6023714000E X-Stat-Signature: cd4jdnamfwggw8qjf4wna1w8drerte9b X-Rspam-User: X-HE-Tag: 1674572401-313087 X-HE-Meta: U2FsdGVkX1/VZVPuLibgo0Jpxp5+kawMhnBbbdrz0Mu/yr2SCQULYG3sLl/b8zVAG25Eg84OCbPxCPlKgH6/lUP48r0nr8uuIngTx0M7zqm0ZlFb4TYEeKSm7jc+ev7EHs6Ozs59F/RS4ePRDfNY2gRtbFGqh4EaoBAKO89ew6LY7klCBdxiRm7e44w5IkgIyy2GoI+kneK3BK5JJ6AAxfUTdmcSLoL/YZJMNfUkJPSsFBclJhCTmTRKCYhScQ0yDjQUyVcw3bY0fKtaeMBS1p6bqGOm1eF2HWpxaDxRo+wZLnuH/Vq6ycjTW9Jzwg6wp4ONwIa5WjyYFzCAGZ7aDbMsiUQyT0bWp5fjcd1EkINTJpAQkQjp8/N593SAdHjyxo1DJA6Wni+MfExVeX81SN/Rs4ukhqEKL1WSSCjmBvTiWV4LZ5wHbi3V9IFoBBpVA3S/Qp7rca2CBCLxpLcbLfQxzYEzDS3FwYDiwj7ZqvCYlRhR6Rdw6+mDuqEwSNt0FGXPTOLMBed3l9sUnO9cNEyKLU2PWEzs0yN+qzqEM8mfCks87sB8+grPDzt8ijJlOvBzR9UUVaFeQ0JZByPEMoc2M8bdsMMC6cWs2qkhbOkor1vIslnCbC0yADm2OPcC3FZIM1HMyf7FxGkKEzs4DTPg8xo3Fv8AcwhS+RQfC7toGdWYurNPjVgGOMWEIPonGiQI3tn01rFq1gBvslh1ylrY5qKkgAhUBzAPAUncgHZCp0yY9gIF/duFNGrNZv79pbuV/kuzCCQN6vGiPTqWF0g7BxW5r6+hfYe55hqy0u0E075Qc+jos8cvfiXKo6w0ss9eP5h4r7LKOcSeY06Lza8vejW1CeNHMSocbH85LHOV99GlIOR63r7iyVoVJFd2NYaSwDVuQEdts9mlgxI8OSwCJTWTItjhk8rMuEVnNFJ+ob7fdGk+29Fooa/VWKnNR2Twih8DQUYj09QcEBE cljsb96D 14A0M6usZZ9U5gpb5K7fHQmzsQUczJi0eg14C+EBrww3WhkrVWBsH7ZvGsfUyROXn70a7KiaXJDSBZfqHOXz/0CEgcpEghTvEQLZmYQ1OATRSsNoWE1XmtlB7itdtL2lvGIn6Sy/DhdayHbaaDR2gpAHIQwx4rfFT5JigaMSTZnVLmpI= 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 23-01-23 19:17:23, T.J. Mercier wrote: > When a buffer is exported to userspace, use memcg to attribute the > buffer to the allocating cgroup until all buffer references are > released. Is there any reason why this memory cannot be charged during the allocation (__GFP_ACCOUNT used)? Also you do charge and account the memory but underlying pages do not know about their memcg (this is normally done with commit_charge for user mapped pages). This would become a problem if the memory is migrated for example. This also means that you have to maintain memcg reference outside of the memcg proper which is not really nice either. This mimicks tcp kmem limit implementation which I really have to say I am not a great fan of and this pattern shouldn't be coppied. Also you are not really saying anything about the oom behavior. With this implementation the kernel will try to reclaim the memory and even trigger the memcg oom killer if the request size is <= 8 pages. Is this a desirable behavior? -- Michal Hocko SUSE Labs