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 5C84CC25B75 for ; Sun, 26 May 2024 13:57:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 871BE6B0082; Sun, 26 May 2024 09:57:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 821466B0083; Sun, 26 May 2024 09:57:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E86E6B0085; Sun, 26 May 2024 09:57:06 -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 5183A6B0082 for ; Sun, 26 May 2024 09:57:06 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 92CF01213F9 for ; Sun, 26 May 2024 13:57:05 +0000 (UTC) X-FDA: 82160698410.26.FEC2EAA Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf02.hostedemail.com (Postfix) with ESMTP id 2A36E8000B for ; Sun, 26 May 2024 13:57:02 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pEoxygiQ; spf=pass (imf02.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716731824; a=rsa-sha256; cv=none; b=NkiTfF+ohGqS1u5WXeiabCm9nrfu8GDSCa6jf+cvgrGfvEmGk5Oqx710R2HkaHmoEV8Rk0 Pn5qPs9hB64V23ga1CCsH7+Tvf/0F74a8sfAjy13j7dMofQ8Hewbj8kLUP0W6Joh36PWvZ dF3+skMu9SRlHZ5QmTHmcmQDELscqlE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pEoxygiQ; spf=pass (imf02.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716731824; 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=jOSPNv/aToVdY1+F64JS4Y/GcyuLSG4g95ZSExjfssg=; b=nbJOOSak3tUNJFJ2Mg7uIN7lrqhu/KAtXNk5li1xaSmhUdeL3YJi/SfHVebCL9uzRO8grH ZSsGALoaouAyN2pJyW4Pky5lCLhkPH4GchsSwk29egfCfhpbtxX8zlpk/Tkt6UIPkdPEMs POZVUpnYZZd/BwBFL6gNbzu1V1iZeIY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id B7BCECE0B29; Sun, 26 May 2024 13:56:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35CFBC32782; Sun, 26 May 2024 13:56:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716731817; bh=5krnBIVZ4dxE084sNLxLTA0q1E2w2NM4RO+BibuxlMs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pEoxygiQ8sk8AedVDHE6TRmYRugAfDR8g8jEx5U7Vbh8pU1Z3SCnLUQMLWFCplcbT y2QPvBdN6By4VqFw2dim0T+zGYfe8dbsEHkfjP1behElRJy5+fHXFYOLSMvtv0I+Bn 0NDRzu/OFfIMD5cgY8WALcRuSEmhoRlN2N8bffaqqPy5Z0V/mULGO+ns7Z5kEejOgL q+D7DVnZEl5RgoUVTQAqb8VJJMtq7hAnGMFGGFET88cW1n9oshJ5ArKNIPpcE/qbF1 EySY8+nG1kNXsWq6UM4tBghyd9cGLsBAMWR/10sTlZ4jRqhxz/poeiQgCG1jYsDJnV bGuzgxu21/1Tw== Date: Sun, 26 May 2024 16:55:01 +0300 From: Mike Rapoport To: Jaewon Kim Cc: "vbabka@suse.cz" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "jaewon31.kim@gmail.com" , "tkjos@google.com" , Wei Yang , Pintu Agarwal Subject: Re: (2) [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory Message-ID: References: <20240521023957.2587005-1-jaewon31.kim@samsung.com> <20240521025329epcms1p6ce11064c0f0608a0156d82fda7ef285c@epcms1p6> <20240521101753epcms1p50443f6b88adea211dd9bbb417dd57cb1@epcms1p5> <20240524090715epcms1p274939a1d5954be3423f6ce14a3df6f92@epcms1p2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240524090715epcms1p274939a1d5954be3423f6ce14a3df6f92@epcms1p2> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2A36E8000B X-Stat-Signature: a7n5ashof676ofgn5r6hpfbr91n6ft1s X-HE-Tag: 1716731822-253596 X-HE-Meta: U2FsdGVkX19w3z3OGMT3Qmi9byYE3djplBTMQUt4Y+NCNyaLDrjvrkVbj0r52du2iWY6QxG2Gvl6NvlSjbI3J2hIccPFpJIkhRqX0vuygYpsBWYzLq4OH8pKc+d+XnYnTQx5an8UWzmfz9vVNNJbU3IGS2ZD23ezrq2xogwVRgQelx4thvPzk9f++bIyFVSsAi+Ek/pReUkiiwFslZY/FwribHeKH/JcjCnLFjnb4UO23tj0tIN6LbZTuPghZKPR/0gG7JgnhasN2DX5qL315EAJP9wVmS5SxN2Jx/6oI01qkka2SISGvPKURDKdmrQaNTV6K9Kb4rS3nu3eoC53U/JZEPaH2y0ep8+529HyN7vM/aBkluIAplfKb7LheBGWXzKN/0ZuCp18lec2EuWNF1K037gnU7xpAj0kW+FdvddTn1zD9FjxMAg1etldzEPVpeRW/cWEz4slzl02O01pbawaQfu25XLefNFkeablRVtttyPu+g1vz84YpZWibXB5h/keGeDCnHTLfAEuQHYyV0kcNu0nCWwjG4SD8x9twYxHWNpAPgscoKTaU381VXGggWDKQwHnSTWuij8QdGZ6wUrqiLSSbT/+KAcJEQunk+LWzQR2m4oT/UgYk/dmGMRdrygFYn6g4EKnM/YjK+c1ROl4IKhj2gB6a4sv6eh3QTjGLrP+l7gkZcp3muhA807mQMt8UxguOZCWz1FpWARlJR+e2mB9hz0K/38xmeGqsORWu+HsTv8TB/2DzVkIYOwFxFckeROuV0bcUfmdot2Z5pPAy8IfcD0ByCnh3qAVZAkIZht6sPSApIHcpRgm9kC40Vsy6i52pkuQjfKZZsGkK7d9M6OZR/jtg4W15peiLrTfNq7Cp0Rk6F2lTnfhhCnUhj+viA+SEsN+YoIZtAOrgHRbPlk7JlRWmlQ45Iv0Gp0vUzbMjkAC6ZOPgllKntUBJ2C93fzmI3XnY7dIkdJ GKQKNwtd W9NcpEN5wrZptxN00b5tiYZcFj3A1AjpGp5m+Xi7RWa7HAsn7D5pPO5hogVfUgpjTmEY8wORjbYhEd+8R4jugegGf2Z8QhoHkgUs3I1rvQfz+Ufixoqxx18yETwK0hoXQUdEZbAMEZpO4GN5HzDfdyetsrtfPC9W8mLnCYtvpHBJyyGyPt5KL+9Zlxy2uVr04Ir+hgUtWJpH4rQSJ1RqhEohY1TkIm5syBZrVumFluiHOL0yJOUm1IUpKfu/+N5g+GJZInI99gzZicYDfEUSH+74i153Nqi6WmB4+HQQpjYI1RUAdExoUibki49f1OpTs6B3Mpj2nkbiBQjc9+kS3XSZssAKcyXybXs1x6zuC3W/P1pgm6o8SMQViTruHgQytdGkYKvtTBMwqOOQzNg6RO+IANQ== 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: Hi Jaewon, Please use reply-all! I just realized my previous reply went off-list :( On Fri, May 24, 2024 at 06:07:15PM +0900, Jaewon Kim wrote: > >On Tue, May 21, 2024 at 07:17:53PM +0900, Jaewon Kim wrote: > >> >On Tue, May 21, 2024 at 11:53:29AM +0900, Jaewon Kim wrote: > >> >> >--------- Original Message --------- > >> >> >Sender : 김재원 System Performance Lab.(MX)/삼성전자 > >> >> >Date : 2024-05-21 11:40 (GMT+9) > >> >> >Title : [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory > >> >> >? > >> >> >Some of memory regions can be reserved for a specific purpose. They are > >> >> >usually defined through reserved-memory in device tree. If only size > >> >> >without address is specified in device tree, the address of the region > >> >> >will be determined at boot time. > >> >> > > >> >> >We may find the address of the memory regions through booting log, but > >> >> >it does not show all. And it could be hard to catch the very beginning > >> >> >log. The memblock_dump_all shows all memblock status but it does not > >> >> >show region name and its information is difficult to summarize. > >> >> > > >> >> >This patch introduce a debugfs node, memblock/memsize, to see reserved > >> >> >memory easily. > >> >> > >> >> This is actually RESEND as it was introduced 2 years ago. > >> >> Please refer to https://lore.kernel.org/linux-mm/YkQB6Ah603yPR3qf@kernel.org/#t > >> >> > >> >> > But you never provided details about *why* you want this information exposed. > >> >> > >> >> For your question, I'd like to say ; > >> >> We can see the same format and exact information between different version of kernel status. > >> >> > >> >> 1) Internally we can check if the reserved memory changes. > >> >> 2) Externally we can communicate between chipset vendors and OEM, with a same format. > >> > > >> >Why the existing debugfs interface is not sufficient? > >> > >> debugfs/memblock/memory & debugfs/memblock/reserved have changed its > >> format but still does not show name, reusable, kernel size. If memory is > >> reserved from memblock, and did not freed back to memblock. Memblock does > >> not know even after the memory is freed to system. I think a simple > >> debug interface is needed to easily communicate with others or compare > >> different SW releases. > > > >I still don't understand what problem are you trying to solve with these > >patches. > > I think we need a common API to easily see the reserved memory status. > Through MemTotal on /proc/meminfo, we can only see only the total size > of reserved memory. We don't how big kernel init size within the the > total size. I think this really helps to compare different kernel and > communicate with others. As was already mentioned on this thread, something like $ dmesg | grep Memory: [ 0.000000] Memory: 8058204K/8388608K available (35392K kernel code, 8706K rwdata, 23320K rodata, 16832K init, 848K bss, 297636K reserved, 32768K cma-reserved) already shows init, rodata and bss sizes. And size -A vmlinux provides detailed breakdown of the kernel image into sections. > I think the debugfs API or early boot log shows quite much information > for the reserved memory information defined in device tree. But it is > difficult to see after boot, as the boot log already was removed ouf of > the kernel log buffer. Kernel log is persisted, isn't it? > And it does not show some information like kernel init size, late free > pages. AFAIK if some memblocks are merged to a memblock data structure, > the debugfs memblock API show it a one memblock rather than showing what > each memblock request. The reason to merge reserved regions is to save memory and CPU and in vast majority of cases it is not important from where memblock_reserve() was called. If it's really important to keep some of the reservations distinct, it can be achieved by e.g. using .flags field in the reserved regions. Your repost of the patches still does not address my comment from two years ago: You propose complex mechanism that seems to fit very particular scenario and sprinkle some calls to this mechanism at random places because you need to "compare reserved memory map with other map". As I said then, I don't mind providing more visibility into reserved memory attributes in general, but I'd like to see something way more simple and localized with a clear description what problem it solves and how it works in a general case. > BR > Jaewon Kim -- Sincerely yours, Mike.