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 E6941C2BD09 for ; Wed, 3 Jul 2024 17:27:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6947C6B007B; Wed, 3 Jul 2024 13:27:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 644B16B0082; Wed, 3 Jul 2024 13:27:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E4B46B0083; Wed, 3 Jul 2024 13:27:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 30B2E6B007B for ; Wed, 3 Jul 2024 13:27:36 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DD3D480DC3 for ; Wed, 3 Jul 2024 17:27:35 +0000 (UTC) X-FDA: 82299123270.30.0A9D5BD Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) by imf24.hostedemail.com (Postfix) with ESMTP id 09442180018 for ; Wed, 3 Jul 2024 17:27:32 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Y9WoHKyN; spf=pass (imf24.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720027629; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IyZPON5O6++ZHw+uOQ1ftlsCqOJ1FTyz/rf8eKpBQ2w=; b=4GACjMEkptcrLNqHZhdpv32ftDp5qH6jnbICi2lfEPrIifcJz0nDAdY4hTmvAESCS0H7Km gXm7xURO/j9UuLfu8WkdZQERYRPTqCzTVLgIJnbs3TwDtxDX0RwlPIA62J2iKLd0RZC8ma aPO9/fLR/Wf+AiI6gPBWcWZtyxByxEQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720027629; a=rsa-sha256; cv=none; b=O4qZ8f1k5YZPd/krOcnERmg+UxvIfxXuBZnpsBE7NSH0nhMkn4TgC6xq8GCd4gNj7fcrkg UGOESK99foRRT5PimvJLN0uvZoBbtXJnTOIY2qNleSRecnkEwZjfDPUHeLfg1tqnTX7QkT ba4dOcIEEp455YNm/khzpny7ECu6qQs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Y9WoHKyN; spf=pass (imf24.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Envelope-To: link@vivo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1720027650; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IyZPON5O6++ZHw+uOQ1ftlsCqOJ1FTyz/rf8eKpBQ2w=; b=Y9WoHKyNvOR3yrZpzen3hMsN5tO7VfI+HQSl8+BSeYtnVxAC1Ec3bH2P1EVOXnntkaY3kz 7V0dqSdBtGdFbdeT4lPGWF0Unbk8eK9dDYlzkLWSbxjdpacMLUTU3qbea6JYFPh5SfAF/e 5t5pOrj19c1JrDfKXPVG43kpZdftikg= X-Envelope-To: roman.gushchin@linux.dev X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: mhocko@kernel.org X-Envelope-To: muchun.song@linux.dev X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: willy@infradead.org X-Envelope-To: david@redhat.com X-Envelope-To: ryan.roberts@arm.com X-Envelope-To: chrisl@kernel.org X-Envelope-To: schatzberg.dan@gmail.com X-Envelope-To: kasong@tencent.com X-Envelope-To: cgroups@vger.kernel.org X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: brauner@kernel.org X-Envelope-To: opensource.kernel@vivo.com Date: Wed, 3 Jul 2024 10:27:25 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Huan Yang Cc: Roman Gushchin , Johannes Weiner , Michal Hocko , Muchun Song , Andrew Morton , "Matthew Wilcox (Oracle)" , David Hildenbrand , Ryan Roberts , Chris Li , Dan Schatzberg , Kairui Song , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christian Brauner , opensource.kernel@vivo.com Subject: Re: [RFC PATCH 0/4] Introduce PMC(PER-MEMCG-CACHE) Message-ID: References: <20240702084423.1717904-1-link@vivo.com> <27a62e44-9d85-4ef2-b833-e977af039758@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <27a62e44-9d85-4ef2-b833-e977af039758@vivo.com> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: j9rj3x74m5fjc5ce3qy88fa7f988ogd4 X-Rspamd-Queue-Id: 09442180018 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1720027652-203801 X-HE-Meta: U2FsdGVkX19xKuvYzbWXC3bG08aS476ezOOD/qzBRNiqpLG4harcv6IGHhTOB2WvP8/ikzGyflLcP0PRQ2IKrH0i48CMASl9ZywunoN7MYGSzvI+JB98LwA+Fdgbe1x7voatEEFmUtACsCQFX9u4+/nEbG8AWd+YhX66gSv0W0JLixAb9a3jnmV2HVL2VhYVcsoeex+X0GaDZmdZiTes1Gi5ls7ZCkA82qV2xEKWynlv2t+EBf3nlmBoqxUmsokYQE8RQGxsxJqGp2V/Nd2c2asO6KkIE/fV30aKuRUAsk79UWSEKSH526cthx2HLOY31EYoUxuFmSBQixtxu1X2AFcTSNraPcrG4nvSZ4PSJj2hGcBIclzrFb/m+n9bQrG/f2dgIAumAQV7O7P4/97zGHGNLCJwChq+5klnpG9Rbvm0JcfiWVYcjPI+CRpz2S9e4nUJss7DsN2ExpN/Bw9SZPUY0Pv17YEAyElsIRQdBObJX77eaVjqjgFkH0n2hwjKik4/Fl3MtRkvbfWmdTh62MeNZgIKbhyLGVaXk5bQGZCHhrUNYzhs9pPlLIK0Zs8tmjKcMB3O47tNJ9xdLW6TbuUdWhe82g1gmxsOdpzhy540WLScwPQhZxMJ3+3tdoG4FaAmOlMuX/N8WduD7I0Crn0Ypn2AJNGyQyzaeucz4acvnFJfhEHvgBGPvn+k7Ol2C8YMIjaZfqddmOOyGVWaJK7cxvbS3J79LGC6g8/iTw6sJ48TIjJMOIvjcY5jh5z5Xb8Ek8584dIfa0NlqaTqZ5mQVjSMm4RRgZMpWTivNnkID2bHqoCqstdFj46p9mhUXRB9r3dgTKuK4SWjrzqRFrr8Hwc0ujnYKbbTVjABi5y7qkpya3iZA/IA5XWPNcOdxj7R0gUBaoPKXIKVhOiaSc7+CB0uzNiKfCA53C6t+p5w+pt6Jd0zdYSMTRHFRmvDsa/JvB4XtTHcEVQhgFy vHLhSXcm Yj+jPS3Wq4tkCl2wjBS/JXgL74cdeMGuW38ZjEVrftORlba7TLE9MWJ5O+9t7A7lIX8bu+jllvfdeQDyH59OHeVBgU7X21UhcwNMj+kDeSm4e1IMNteEo5wDBX3D19zUrPa3y8fe3V/moEyai2n8xS+Q2qX6r5fv7mzJv8QyDMn4XLGgq4QDY3QMt5jUf8OpMEsoB1RbxyEj/sRUyszQv5/Jf+ljkP1QvYQR+ 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: List-Subscribe: List-Unsubscribe: On Wed, Jul 03, 2024 at 10:23:35AM GMT, Huan Yang wrote: > > 在 2024/7/3 3:27, Roman Gushchin 写道: [...] > > Hello Huan, > > > > thank you for sharing your work. > thanks > > > > Some high-level thoughts: > > 1) Naming is hard, but it took me quite a while to realize that you're talking > Haha, sorry for my pool english > > about free memory. Cache is obviously an overloaded term, but per-memcg-cache > > can mean absolutely anything (pagecache? cpu cache? ...), so maybe it's not > > Currently, my idea is that all memory released by processes under memcg will > go into the `cache`, > > and the original attributes will be ignored, and can be freely requested by > processes under memcg. > > (so, dma-buf\page cache\heap\driver, so on). Maybe named PMP more friendly? > :) > > > the best choice. > > 2) Overall an idea to have a per-memcg free memory pool makes sense to me, > > especially if we talk 2MB or 1GB pages (or order > 0 in general). > I like it too :) > > 3) You absolutely have to integrate the reclaim mechanism with a generic > > memory reclaim mechanism, which is driven by the memory pressure. > Yes, I all think about it. > > 4) You claim a ~50% performance win in your workload, which is a lot. It's not > > clear to me where it's coming from. It's hard to believe the page allocation/release > > paths are taking 50% of the cpu time. Please, clarify. > > Let me describe it more specifically. In our test scenario, we have 8GB of > RAM, and our camera application > > has a complex set of algorithms, with a peak memory requirement of up to > 3GB. > > Therefore, in a multi-application background scenario, starting the camera > and taking photos will create a > > very high memory pressure. In this scenario, any released memory will be > quickly used by other processes (such as file pages). > > So, during the process of switching from camera capture to preview, DMA-BUF > memory will be released, > > while the memory used for the preview algorithm will be simultaneously > requested. > > We need to take a lot of slow path routes to obtain enough memory for the > preview algorithm, and it seems that the > > just released DMA-BUF memory does not provide much help. > > But using PMC (let's call it that for now), we are able to quickly meet the > memory needs of the subsequent preview process > > with the just released DMA-BUF memory, without having to go through the slow > path, resulting in a significant performance improvement. > > (of course, break migrate type may not good.) > Please correct me if I am wrong, IIUC you have applcations with different latency or performance requirements, running on the same system but the system is memory constraint. You want applications with stringent performance requirement to go less in the allocation slowpath and want the lower priority (or no perf requirement) applications to do more slowpath work (reclaim/compaction) for themselves as well as for the high priority applications. What about the allocations from the softirqs or non-memcg-aware kernel allocations? An alternative approach would be something similar to the watermark based approach. Low priority applications (or kswapds) doing reclaim/compaction at a higher newly defined watermark and the higher priority applications are protected through the usual memcg protection. I can see another use-case for whatever the solution we comeup with and that is userspace reliable oom-killer. Shakeel