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 28F63C02182 for ; Tue, 21 Jan 2025 18:31:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B3CD6B007B; Tue, 21 Jan 2025 13:31:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 663CB6B0082; Tue, 21 Jan 2025 13:31:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 552B36B0085; Tue, 21 Jan 2025 13:31:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 37FB16B007B for ; Tue, 21 Jan 2025 13:31:10 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9803F140F55 for ; Tue, 21 Jan 2025 18:31:09 +0000 (UTC) X-FDA: 83032301058.29.4B7C0DE Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf07.hostedemail.com (Postfix) with ESMTP id C6C8940015 for ; Tue, 21 Jan 2025 18:31:07 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FZE0klih; spf=pass (imf07.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737484268; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BIL1cb2mcAsf0PUN52InGXQTqII5KOC2XjFJUGCxiTg=; b=qItZ/D+OnhCSJciWWGFxPTyvLO2u5nCmEPjmf9JyiFLIQ8mSkC6lSk5U17EztZOSkaosLr 704mUyPikgWntwpgOKK01DFfiq8jgkWyJLo7kKOFx+FdEtUn9nIrDYiyQoI8YCmUmWG+8d vHHguN54B9RK4vpGwmT4k3QCdjox5iI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737484268; a=rsa-sha256; cv=none; b=X/BGKNknxckMcTmSXvgk5zdAQ2NEELJ/KyC3A6Tgiu5k6yOOpGQmpnIQHS8enQKYfFFJiK 4FeDJCQngQXA7ZUll79ckrhzvuaZ2vqlZQxWiacyLdaqXTE82TVrtAo5laRxt5Xzpe22YE z88ziX2qvt1VAYqjWjEz75Dznv0SIcw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FZE0klih; spf=pass (imf07.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6160FA41F71; Tue, 21 Jan 2025 18:29:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E629C4CEDF; Tue, 21 Jan 2025 18:31:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737484266; bh=3QK29OxTAWfOE3Bh19Uk+uWELwGskeUDh7NhxreP0gY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FZE0klihaNkrx0B0f7zUZtcZg98jjQgFzow5JKwqwz/0cuWIxKdqJn6yAhqfUzxsA IH6+mTJ5HhG++fj5iZNinJAHeTMoWpdEIx6okj5yZc7aGzgku4XIdt2BAnvovlaFEm ryZsA3ZP8Jea/rthmYoXkH8r5ivXZTMwtyQ9PzkFTZiurNZTOCZxeNbWRx2iwEjqzU 8nCB0X7T+w8LICiJRw8fiWSCRIavsT/Xz6BvjQyzW4Dz4nEh+VedG0gYe8VwP82JRL qlOFTxLXtz/o0mO1NjOiPtj9+3VrsaliqIAp4h1yTSviUT2NBoG5nJG4bjC9fakPtx eC0DU6NUiq7Bw== From: SeongJae Park To: Jonathan Cameron Cc: SeongJae Park , lsf-pc@lists.linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [LSF/MM/BPF TOPIC] DAMON Updates and Plans: Monitoring Parameters Auot-tuning and Memory Tiering Date: Tue, 21 Jan 2025 10:31:03 -0800 Message-Id: <20250121183103.42877-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250121100145.0000398a@huawei.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: ncgehwp19oonywfqtojo6rbswz67u7nd X-Rspam-User: X-Rspamd-Queue-Id: C6C8940015 X-Rspamd-Server: rspam03 X-HE-Tag: 1737484267-462707 X-HE-Meta: U2FsdGVkX19WCw9pN6uLuRRe7gG27qn2taGJNHA6jzgf6pSshRD6+y+Lzbj4sZcxJJsqI8HEs4npvOOpfJ+uXg5xTEy17NXv6JvoV56XgzCX9oeEGdY2I7f939qNlyqXSE3YMouvF3fRkhdc61aNDbgvfWusIKA4hMioaOICKWCwDajDTnHcVd9OeziondOtvCpa+NSymm4JeiHzwtUftzfeHpTulppDZmAy0ri95DpdhIxZhdSmDSw0b6l/BY7svt0L04EZ3vf+EtnGLwIh0+x0vUhwvf4VG8V4TetZ0d6QC8kuJ3osXTmJRG+ovn/ZMAd6SdwOC051RusoO3R3hNNuiXygpG9lbir4r6ri5qKWk8bShMI0tPRNs1GyqkWmIVFRD1iUsIsLEQHLtMJKuQcOLSbzkH0mg5U4d2K7GLKu6tqGLzl3ttwugxmR++v9gRKSEwTUJh/nuudybeWhzcPRxyg8NJL1dZkIgpTfUvxPBan5kK8b7FUGVNgWmh5pqMGdNxVBo80EH3RAJDNeEKQ0IwWtH7+dplFyb9oOH6Bq8RXvnnU5X0+omWCBeI9hU4NVgopDzleXuJ3dXnj5Fl9bN2/AEWDIoY34s1Ml6RMnlwfKT4680wtz6FjWQInG2vJWZSErOyKOVoc+Oe117JuLyb/pNwB4BQXLmQ4bF3SZIX6z6BEzd7ioWx91jm2n+V6LTMyKvoQOXXnOlVgfUXBgLg0E04gOGN+VId12pQ3Mow1ANJXa7H7yQks8+ifNAr0QYXGu3XvqKaYyYnLOM5OdTl3NvXTWiZtSKw5xcG3A39MamW9NnF793UK0JVvvGc3v9E5ccxGyoqzNrWqiLinTWDmZOlfQ5hbDrL9b8plrOf/fvRKPZ9z/ePoDPxH+YWyl24PCEDLlBmqsjNZPahHrfBjvzt4j58qb1FDCYXllRcb55RV1MXuzXaSzCbjHWDrUMNIrx2sKk0gCzr4 gpEmVvp6 hslQpcDzLGo3+Nd6PzbNkgk1v+Z8f+eIuSFN3Q4PSd048T2sSFTFQ5dH77xHZvwqg0ljx8IOv1J1qqOVv7LFF3LYciiK0337+6pfcvWUHHsfy+RbObqY9KsXmatV0OuZMc8rmhZ02hq5YbvTg+pEJ1IG3YrGWVKDceJ1koHbLQScf1CdAplYz2CsvqXuM3hmaiVabIGRiWppWA9kgRPcGqV/OVCfupZzanKIls7acf47sn3jLLOsmwQebJPSdHWs8LjK5Wm8DCEOAtjncN8QrJuJ6myrT8Fxsr11uQ0yjtTZUFfAjhJ0vgeH2xalDQYjuKBqEVNCtvJHe1rXW1z/IVktJrjeInm/M9thewGNN7njcKa8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Jonathan, On Tue, 21 Jan 2025 10:01:45 +0000 Jonathan Cameron wrote: > On Thu, 2 Jan 2025 14:23:17 -0800 > SeongJae Park wrote: > > > Hi all, > > > > > > We started sharing and discussing DAMON's current status and future plans from > > LSF/MM/BPF 2023. Thanks to the constructive feedbacks from the discussions, I > > believe DAMON is continuing the evolution in right or at least not > > controversial directions. To continue getting the benefit and avoid it becomes > > an unexpected "demon" in early stage, I'd like to share and discuss followup > > updates and new plans for DAMON once again on LSF/MM/BPF 2025. > > > > Major topics and currently expected materials to share on the session include > > below. Of course, some changes could happen. > > > > First, followups on work items that we discussed on last LSF/MM/BPF. > > > > DAMOS auto-tuning based tiered memory manamgent. No many progress has made so > > far. But I recently gained an access to a tiered memory system, and setting up > > test environment. Hopefully I will be able to share early RFC implementation > > and evaluation results by the session. > > > > Access/Contiguity-aware Memory Auto-scalging. No progress has made so far, > > too. I'm pivoting this into reliable huge contig memory occupation > > mechanism, though, since it is smaller scope that we can make faster. It can > > also be used for not only memory hotplugging based auto-scaling but also > > contiguous memory allocation. Hopefully early evaluation of a part of the > > work, probably access-aware partial compaction, will be shared by the session. > > Hi SJ, > > I couldn't immediately identify the huge contig memory occupation mechanism proposal > in last year's slides. Perhaps a brief summary here? The idea is (too) briefly described on slide 45. Thank you for asking more clarification. The idea is to proactively and gradually occupying contiguous memory regions starting from cold ones, and then use the occupied huge contig region for other relevant use cases such as contiguous memory allocation pool. For example, 1. Find 1G coldest region of the memory that not yet occupied. 2. Find 2 MiB coldest region in the 1G region, and try alloc_contig_range() it. If alloc_contig_range() succeed, keep it until other kernel components (in this example, contiguous memory allocator) ask it. 3. repeat 2 until the entire 1G region is occupied. 4. repeat 1-3 if more 1G contig regions are needed. For more advanced implementation, we can also do 1-3 in parallel, set the occupying candidate nearly-located, let limited number/size of holes in the contiguous occupied regions, etc. > > > > > Please refer to last year LSF/MM/BPF slides[1] for details of the above two > > projects. > > > > And new projects that currently in their early stages. > > > > Page level properties-based access monitoring. We are extending DAMOS filters > > that works in page level properties to further be useful for monitoring > > purpose. RFC patch series for the essential part[1] is already available, and > [1] seems to be last year's slides? Was that your intent? No, that was not my intent, sorry. The latest version of the patch series is available at https://lore.kernel.org/all/20250106193401.109161-1-sj@kernel.org/ It is also now merged in mm tree. > > user-space tool support[2] is made. By the session, hopefully the patch series > > will be merged in mm tree, and I will be able to share followup plans for > > making it more lightweight and useful. > > > > Extending DAMON for memory bandwidth monitoring. We aim to extend DAMON to > > support not only access pattern snapshot generation, but more general access > > pattern information, like memory bandwidth usage. I expect only rough idea > > will be shared on the session, to make early alignemnt of the future shape, or > > abortion. > > > Where does this fit alongside hardware aided solutions (resctl - MPAM on ARM, > similar stuff on x86?) Idea to do it at sub process granularity? I have no good answer at the moment. I need to further research. Hopefully I will give you a better answer by LSFMMBPF. > What are the use cases for that? It is a very early stage, but I'm thinking about using it for helping CPU scheduling, and page migration. > > One other topic, can we differentiate read access from write accesses? This is one of DAMON's todo item. Actually there were non-public requests to implement this, though unfortunately it was not prioritized so far. There is also an RFC implementation that uses soft-dirty mechanism: https://lore.kernel.org/lkml/20220203131237.298090-1-pedrodemargomes@gmail.com/ My current plan is to use PROT_NONE page faults or AMD IBS-like features instead of soft-dirty. > The promotion costs for the two may be somewhat different if we can keep the > old translation live until the copy is in place for read only. Taking that > into account in promotion decisions may be useful. > > Being able to track separately is one thing the hardware tracking units > do well subject to tracking resource constraints. Agreed. I'm planning to play with AMD IBS in specific. I may start from PROT_NONE page faults first for early prototyping, though. I will try to share an RFC prototype, or at least more detailed design by LSFMMBPF. Thanks, SJ > > Thanks, > > Jonathan > > > > > Please let me know if you have interest in status of other projects that I > > shared on last LSF/MM/BPF session or somewhere else. Depending on that, the > > topics and time portions can be changed. > > > > Note that I proposed[3] yet another LSF/MM/BPF topic for DAMON. If both are > > accepted, please schedule this one before the other one. I believe this > > session can make the other session deduplicated and faster. > > > > [1] https://github.com/damonitor/talks/blob/master/2024/lsfmmbpf/damon_lsfmmbpf_2024.pdf > > [2] https://damonitor.github.io/posts/damon_sz_filter_passed/ > > [3] https://lore.kernel.org/20250101222039.74565-1-sj@kernel.org > > > > > > Thanks, > > SJ > >