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 3E5A3C05027 for ; Mon, 23 Jan 2023 21:27:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70D376B0071; Mon, 23 Jan 2023 16:27:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BDA76B0072; Mon, 23 Jan 2023 16:27:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5859B6B0074; Mon, 23 Jan 2023 16:27:15 -0500 (EST) 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 47AB16B0071 for ; Mon, 23 Jan 2023 16:27:15 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 15B66160530 for ; Mon, 23 Jan 2023 21:27:15 +0000 (UTC) X-FDA: 80387349630.24.42E2C63 Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by imf18.hostedemail.com (Postfix) with ESMTP id 644CA1C000B for ; Mon, 23 Jan 2023 21:27:13 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="iGe2Fv/+"; spf=pass (imf18.hostedemail.com: domain of talumbau@google.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=talumbau@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674509233; 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=jDdvKKY6vXKD/b+VRce+QXw9nBIr50kKl6fkjfVvZeQ=; b=dDIliltt4x9A9DpE7AOoShGrpZ07xIT4m6rp+CX04Eoopf+/PThh07YBzr71kif2KCQ6Jm khlcqE36HFkhKmjdEXysBPfwjJiVqgjLzKuwjd65pk5zIANuYuLjoPmeEMh95Q5VWLm+1/ kehrSEOqobtZmllPphuv+QBZLNOXRY4= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="iGe2Fv/+"; spf=pass (imf18.hostedemail.com: domain of talumbau@google.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=talumbau@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674509233; a=rsa-sha256; cv=none; b=YLktX7F46b1eGUR8yMgCywxfIlxVOB6zwbVtmrWaaIuW3R9HL/upLQAlafQln+tE3LqR6c CAJF3yDhTPyuGkjR6LYyS2r5PVQTeLBxTfkWjnDLmDo/HOv1KzlgnNwSM9afm072zp7b+f oTThbvGcNd+KJNNutZ9o+PCY+B0UOHs= Received: by mail-io1-f44.google.com with SMTP id b127so6224180iof.8 for ; Mon, 23 Jan 2023 13:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jDdvKKY6vXKD/b+VRce+QXw9nBIr50kKl6fkjfVvZeQ=; b=iGe2Fv/+NXwoftR7t8rC953/eZ013rEQ4mBrdt8X9MzNkxMlldK1FT1JvwVd1t2oTa wzt3oK7AQ4pAuDF97gMa3ELDfzuiAPv2Sj6Se4Q8V/18I8Smqebnz75/5jqt/OqIVno1 WGAz4o5YbBc6PhfxTSoN3tEK/3lw4PEwRg2QcPp3M9UNmGaGIPjKAmHJ71g/sWvKwVpV uS+jSM/nCuWJJMaknBdzwZaj7BZzgYtRH3I96fVSl4km4WJG+B2zY/RW6id3JJhxFf0B QKznnqt8fScD5DU8shOa7RZGkcigl4jxEbuD3jZT+W9E32zLgkcS9gKPeuGDZl14/ySp Wumg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jDdvKKY6vXKD/b+VRce+QXw9nBIr50kKl6fkjfVvZeQ=; b=kRJBZAGP9YlKzgHqIoh+6yHnCzktwNtpDmuO3XCQrQX7iFNqFH9O4iS12lHOYiWfmu I3XmG2Fe6JtFzV5rT6n6s/0El1bHRX8eFr/ic4ETrXqbKnHWD83R6TJMQoDCioOIVg0B za9H3y4FTMVsptphC2wxuwWAZS55GF5BHsCIp9SSZT3tPjfVBAwnJIF0UOphcizjxINK cZO8ovhU9c1yZS75/6Lx2gap2tf9HLxIs4R4EnWJ0xZvWoukGsFgwwZ7/3reKmGMnd/c iJZrIeJIE/oO+jyyGI0a/bVnwSgaMWOxjkGSY76V283BCgSiIl5nf4sRE4JBlpigYGi7 xOBA== X-Gm-Message-State: AFqh2krEUjhm+NbrE6BPoGNsxTGFzXAWjDWqdB00zjN5YSHADaTsNEqM 25GyLyaLqn4RDiwMp7dJUmZeNHCCHA+TQO7gMbzbiw== X-Google-Smtp-Source: AMrXdXvugBkUlkAE0J84vm8n8+OXi1gfzdkJrM86OXIf0grqvMPwRN3cym8TAc6y9qi0UP+ChtOcMLoFU3K2eooeb88= X-Received: by 2002:a6b:4108:0:b0:704:8263:b926 with SMTP id n8-20020a6b4108000000b007048263b926mr1952152ioa.53.1674509232247; Mon, 23 Jan 2023 13:27:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "T.J. Alumbaugh" Date: Mon, 23 Jan 2023 13:26:36 -0800 Message-ID: Subject: Re: [RFC] memory pressure detection in VMs using PSI mechanism for dynamically inflating/deflating VM memory To: "Sudarshan Rajagopalan (QUIC)" Cc: David Hildenbrand , Johannes Weiner , Suren Baghdasaryan , Mike Rapoport , Oscar Salvador , Anshuman Khandual , "mark.rutland@arm.com" , "will@kernel.org" , "virtualization@lists.linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , "Trilok Soni (QUIC)" , "Sukadev Bhattiprolu (QUIC)" , "Srivatsa Vaddagiri (QUIC)" , "Patrick Daly (QUIC)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 644CA1C000B X-Stat-Signature: qs4i9ibwxsibscz71rma4rwk97a1xtgh X-Rspam-User: X-HE-Tag: 1674509233-386382 X-HE-Meta: U2FsdGVkX19aRJqAA+aCVYeTmaLsR3RmKWmtGERHeTdEqHKCLqqNSdOR5qayxGIbQsI4io+LMDXJoEfDHTvoAsYZcArm8WujoM3j+YYnPbtBZfHhVnN/wEQuhPx4g4NObpzB2VXf2S4KDGza6QqRZMQl5vuxnxccS6c7NGhuWbBN7IshM6ekqQxQsiu1IL+OZMUA2/Mr22cc5/+w3X11FPzycCWdKjBj5m8stKJzbwjCmCNayD9i9rkchBrx/m9E5Aav2Ir8UCQ//vart8zEOZtCMYpMohyCEUDxuJuVYV0lmx5hoJ5nRCVWEvl4moHKWDdL6c7tFLe2uUD8WPG83FHB5mSSvGI6rnoWbqfAG8nOQ9rbPCojmNqqQRiS7uz1LOYwDc3J1qa7mveWvok7LhMNBa5yiJR6MoQ5ncvIxZe4tmNXY4fUEt+UvFiu1VLfbPVB1HuWNPj26eEbi1azw5AWHV6S/XAP3zaUjlmPjJ1xoaoiHepO5PSn9XdqJIf5po54lk3EObTC1iS3WSB/uO8XFxBrClqpBBV0LViQNdz41UUZUBKr4BXvtDFUlg8UXU5gOMLAfm9E/qXnc36+GdFWbPiK/7AWOeyIWc7lrO8QHN8iMZcNz40kDFHiJgLyg7Kz/GzaroDfDrJv5QtGwTkyen/xFr3HhvDSqDHyuU9KJPG9639/FBB+BL4aSFdXlBrCHS9rjVgCGi/IYgDSdebtxcqgIew56mDi0SgvKgpJi9+4OSjZVu0/YfqFv7AKmvNchyw6eA09vrCmd1LrjfzAzpedOl3j/VR0dhrYp7EhUAE+k0+qg8h4+ON5xQdr91cEE30//GlobYE3W4IV0v0eGkePEhA80gqwNocmxuZVuG1b/Vnoasfyf0GTIPdT4h7q2xSUXF6HFzwoOWIrIreQv27btSkfDBUI5YgekWqtqcLx+F9KQBs7+Vc3TIQK+T2ZfMbF8WFWU2WtY6M uHEbmWZP T2WANDoobw58BNwFaqRW8EjW2nNVdELsL5CExvoUsPB/qJyv7zbfFWLPeZHUmN/5uGVyOQCJohQJS9/cKnDhBP/UALS56cIkncSOnFjiM+MIbYCVOcuTCelEf1EN62zYSFT4TUluFeHZD+teCf3eYX/Kk4MpDx4FlT3jojHSEy1oBC/v4at3lXVdimSFJ4CZ5Tv0lj6+QMHdOmgSsGIDiUSwEbxhz3XwjvH4tlB33kkwFwJuIvmoZGvrZTb1nKvFCTX+uXbgZekjj+rnxZEUgCnUdK041lw34xHEY3Lxshf0I1kNvb4WLoW1L6A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001355, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Sudarshan, I had questions about the setup and another about the use of PSI. > > 1. This will be a native userspace daemon that will be running only in th= e Linux VM which will use virtio-mem driver that uses memory hotplug to add= /remove memory. The VM (aka Secondary VM, SVM) will request for memory from= the host which is Primary VM, PVM via the backend hypervisor which takes c= are of cross-VM communication. > In regards to the "PVM/SVM" nomenclature, is the implied setup one of fault tolerance (i.e. the secondary is there to take over in case of failure of the primary VM)? Generally speaking, are the PVM and SVM part of a defined system running some workload? The context seems to be that the situation is more intricate than "two virtual machines running on a host", but I'm not clear how it is different from that general notion. > > 5. Detecting decrease in memory pressure =E2=80=93 the reverse part where= we give back memory to PVM when memory is no longer needed is bit tricky. = We look for pressure decay and see if PSI averages (avg10, avg60, avg300) g= o down, and along with other memory stats (such as free memory etc) we make= an educated guess that usecase has ended and memory has been free=E2=80=99= ed by the usecase, and this memory can be given back to PVM when its no lon= ger needed. > This is also very interesting to me. Detecting a decrease in pressure using PSI seems difficult. IIUC correctly, the approach taken in OOMD/senpai from Meta seems to be continually applying pressure/backing off, and then seeing the outcome of that decision on the pressure metric to feedback to the next decision (see links below). Is your approach similar? Do you check the metric periodically or only when receiving PSI memory events in userspace? https://github.com/facebookincubator/senpai/blob/main/senpai.py#L117-L148 https://github.com/facebookincubator/oomd/blob/main/src/oomd/plugins/Senpai= .cpp#L529-L538 Very interesting proposal. Thanks for sending, -T.J.