From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7E435A0552; Thu, 20 Oct 2022 21:50:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C7F9410D1; Thu, 20 Oct 2022 21:50:32 +0200 (CEST) Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by mails.dpdk.org (Postfix) with ESMTP id A452540FAE for ; Thu, 20 Oct 2022 21:50:30 +0200 (CEST) Received: by mail-pg1-f175.google.com with SMTP id e129so492020pgc.9 for ; Thu, 20 Oct 2022 12:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=DoGCx728M0KsT9v+3nevjxq98oZdDRqHAzYHVnkGaXE=; b=tSI2gkvL19L2gP7PF1k8icp0+XroH2SURFVZvbMmS40n/U40SqQ1S/aEGvGuv7Pp7+ 3VdmFf92hc93AnSr794yVMnhDknD2cZCRQmUEbPbd/6rVvmvttlXcJa/93M4yxipP9/Z WLkTj02sZunpT9DKZjiUnXAfn3gUdF44oGIEz1PliPCu8FSYTnUORYAivirW/G5UFvY4 DNAuxILVEsCs+JMDxd6oMIF1wtPkyVljintdjh5niS5lmavkqtqG3kfBZBlJPL0vEZwl O0QQInCN7zw3HuRfcxmJ7rhM4f30lrtE6VMZgpoHuhG0HCIvfccHwB0c9ai5Xr6MyJOd 1PZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DoGCx728M0KsT9v+3nevjxq98oZdDRqHAzYHVnkGaXE=; b=WGw4WNuYE29WrcEa8AQhYHABifB7LZMdG8/66xNXhyK1Rkpy1kAHZDkDlL9PqqnNt8 cJpEJPFMGH8ty5Z3na3juplCXk8ekdpliP4flRFfRnLwyOarkSYUX8WmnoHzoKc/9a+q CE1VqLQ3o4atWefFaq+p/J/mWyQ5dekfYDKRktSJ3p/YOndqQ3jT3JFtnB1Syvhr8oy9 VNu1C46n+Q2B0oN6DLzPOl5K98udoGOgA1LiZduXJ2YZz6BfixvZGxEi5CORcNptmmVX CeYrBvy403miRTSnPY1LLStG/uY4hkNKYK2z3kKV29qTXwjttam78/NvcE/drV6+QOvx HkAg== X-Gm-Message-State: ACrzQf20Z6zxO+wqIdJxUu1RdHmma6VV3Fi7BBJI7d12ADvG5R/b2ljQ EtowYHMrEWa+rgMT3Japrvgs2g== X-Google-Smtp-Source: AMsMyM4h7Wo2v1cHS9ns/sW2tV99B1/LCa5sf9ekIgSf0Xq+XBfccpymB/itIs/tUKbP0yKKb0meAg== X-Received: by 2002:a63:6bc5:0:b0:460:bd9a:64b8 with SMTP id g188-20020a636bc5000000b00460bd9a64b8mr13337726pgc.257.1666295429427; Thu, 20 Oct 2022 12:50:29 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id 184-20020a6217c1000000b005623a138583sm13713588pfx.124.2022.10.20.12.50.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Oct 2022 12:50:29 -0700 (PDT) Date: Thu, 20 Oct 2022 12:50:27 -0700 From: Stephen Hemminger To: Dmitry Kozlyuk Cc: Amit Prakash Shukla , David Marchand , Thomas Monjalon , Anatoly Burakov , "dev@dpdk.org" , Jerin Jacob Kollanukkaran , "bruce.richardson@intel.com" , "ciara.power@intel.com" Subject: Re: [EXT] Re: [PATCH v5 2/2] mem: telemetry support for system memory information Message-ID: <20221020125027.01079a56@hermes.local> In-Reply-To: <20221020221827.73275090@sovereign> References: <20220525103352.1806937-1-amitprakashs@marvell.com> <20220929114313.1346972-1-amitprakashs@marvell.com> <20220929114313.1346972-2-amitprakashs@marvell.com> <20221020221827.73275090@sovereign> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, 20 Oct 2022 22:18:27 +0300 Dmitry Kozlyuk wrote: > > > > I will send out a v6 if the above solution is fine. > > > > > > > > > > > > > > > > 1. /sysmem/sys_heap_list > > > > The commands displays the arenas currently in use. > > > > Example: > > > > --> /sysmem/sys_heap_list > > > > {"/sysmem/sys_heap_list": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]} > > > > > > > > > > I am unsure about the command names. > > > > > > Those commands are really low level and tied to glibc malloc. > > > It is unlikely we will have an unified naming with other libc/OS. > > > > > > I would prefer another pair of eyes, especially on this patch. > > > Dmitry, Anatoly? > > I agree with David. > > Microsoft CRT provides completely different statistics. > I can't say for FreeBSD. > Even if GNU libc is used, the process can be run with jemalloc, for example, > and this statistics become meaningless then. > What is "system" memory, anyway? It can be acquired bypassing malloc, > it can be hugepages mmap'd without DPDK, etc. > > What is the task this API must solve? > My guess is that monitoring needs to know how much physical memory > 1) the process uses and 2) how much it can use, so on Linux this API > could be implemented using getrusage() and getrlimit(). > I don't think that a fully portable implementation is possible, > but at least API will be unified. NAK You are opening a mess here. The malloc_info() exporting XML also means you have to parse the crap. Telemetry to should stick to the DPDK environment and not try to support looking at other parts of the system. Otherwise, it risks becoming tied to one OS and version.