From: David Hildenbrand <david@redhat.com> To: Oscar Salvador <osalvador@suse.de> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Dan Williams <dan.j.williams@intel.com>, Daniel Vetter <daniel.vetter@ffwll.ch>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>, Dave Hansen <dave.hansen@linux.intel.com>, Keith Busch <keith.busch@intel.com>, Michal Hocko <mhocko@suse.com>, Qian Cai <cai@lca.pw>, Eric Biederman <ebiederm@xmission.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, Tom Lendacky <thomas.lendacky@amd.com>, Brijesh Singh <brijesh.singh@amd.com>, x86@kernel.org, kexec@lists.infradead.org Subject: Re: [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources Date: Wed, 24 Mar 2021 12:28:21 +0100 [thread overview] Message-ID: <8aa6af09-6f8b-1f50-820f-90eab0993f1c@redhat.com> (raw) In-Reply-To: <20210324111835.GA18855@linux> On 24.03.21 12:18, Oscar Salvador wrote: > On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote: >> It used to be true that we can have busy system RAM only on the first level >> in the resourc tree. However, this is no longer holds for driver-managed >> system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on >> lower levels. > > Let me ask some rookie questions: > > What does "busy" term stand for here? IORESOURCE_BUSY - here: actually added, not just some reserved range / container. > Why resources coming from virtio-mem are added at a lower levels? Some information can be had from ebf71552bb0e690cad523ad175e8c4c89a33c333 commit ebf71552bb0e690cad523ad175e8c4c89a33c333 Author: David Hildenbrand <david@redhat.com> Date: Thu May 7 16:01:35 2020 +0200 virtio-mem: Add parent resource for all added "System RAM" Let's add a parent resource, named after the virtio device (inspired by drivers/dax/kmem.c). This allows user space to identify which memory belongs to which virtio-mem device. With this change and two virtio-mem devices: :/# cat /proc/iomem 00000000-00000fff : Reserved 00001000-0009fbff : System RAM [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM 148000000-14fffffff : System RAM 150000000-157ffffff : System RAM [...] 334000000-3033ffffff : virtio1 338000000-33fffffff : System RAM 340000000-347ffffff : System RAM 348000000-34fffffff : System RAM [...] For dax/kmem it comes naturally due to the "Persistent Memory" and device parent resources like: 140000000-33fffffff : Persistent Memory 140000000-1481fffff : namespace0.0 150000000-33fffffff : dax0.0 150000000-33fffffff : System RAM (kmem) 3280000000-32ffffffff : PCI Bus 0000:00 Thanks -- Thanks, David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com> To: Oscar Salvador <osalvador@suse.de> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Dan Williams <dan.j.williams@intel.com>, Daniel Vetter <daniel.vetter@ffwll.ch>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>, Dave Hansen <dave.hansen@linux.intel.com>, Keith Busch <keith.busch@intel.com>, Michal Hocko <mhocko@suse.com>, Qian Cai <cai@lca.pw>, Eric Biederman <ebiederm@xmission.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, Tom Lendacky <thomas.lendacky@amd.com>, Brijesh Singh <brijesh.singh@amd.com>, x86@kernel.org, kexec@lists.infradead.org Subject: Re: [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources Date: Wed, 24 Mar 2021 12:28:21 +0100 [thread overview] Message-ID: <8aa6af09-6f8b-1f50-820f-90eab0993f1c@redhat.com> (raw) In-Reply-To: <20210324111835.GA18855@linux> On 24.03.21 12:18, Oscar Salvador wrote: > On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote: >> It used to be true that we can have busy system RAM only on the first level >> in the resourc tree. However, this is no longer holds for driver-managed >> system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on >> lower levels. > > Let me ask some rookie questions: > > What does "busy" term stand for here? IORESOURCE_BUSY - here: actually added, not just some reserved range / container. > Why resources coming from virtio-mem are added at a lower levels? Some information can be had from ebf71552bb0e690cad523ad175e8c4c89a33c333 commit ebf71552bb0e690cad523ad175e8c4c89a33c333 Author: David Hildenbrand <david@redhat.com> Date: Thu May 7 16:01:35 2020 +0200 virtio-mem: Add parent resource for all added "System RAM" Let's add a parent resource, named after the virtio device (inspired by drivers/dax/kmem.c). This allows user space to identify which memory belongs to which virtio-mem device. With this change and two virtio-mem devices: :/# cat /proc/iomem 00000000-00000fff : Reserved 00001000-0009fbff : System RAM [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM 148000000-14fffffff : System RAM 150000000-157ffffff : System RAM [...] 334000000-3033ffffff : virtio1 338000000-33fffffff : System RAM 340000000-347ffffff : System RAM 348000000-34fffffff : System RAM [...] For dax/kmem it comes naturally due to the "Persistent Memory" and device parent resources like: 140000000-33fffffff : Persistent Memory 140000000-1481fffff : namespace0.0 150000000-33fffffff : dax0.0 150000000-33fffffff : System RAM (kmem) 3280000000-32ffffffff : PCI Bus 0000:00 Thanks -- Thanks, David / dhildenb _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2021-03-24 11:29 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-22 16:01 [PATCH v1 0/3] kernel/resource: make walk_system_ram_res() and walk_mem_res() search the whole tree David Hildenbrand 2021-03-22 16:01 ` [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources David Hildenbrand 2021-03-22 16:01 ` David Hildenbrand 2021-03-22 16:10 ` Dan Williams 2021-03-22 16:10 ` Dan Williams 2021-03-22 16:10 ` Dan Williams 2021-03-23 9:40 ` David Hildenbrand 2021-03-23 9:40 ` David Hildenbrand 2021-03-23 11:07 ` Andy Shevchenko 2021-03-23 11:07 ` Andy Shevchenko 2021-03-23 11:06 ` Andy Shevchenko 2021-03-23 11:06 ` Andy Shevchenko 2021-03-23 11:25 ` David Hildenbrand 2021-03-23 11:25 ` David Hildenbrand 2021-03-23 14:33 ` Baoquan He 2021-03-23 14:33 ` Baoquan He 2021-03-24 11:18 ` Oscar Salvador 2021-03-24 11:18 ` Oscar Salvador 2021-03-24 11:28 ` David Hildenbrand [this message] 2021-03-24 11:28 ` David Hildenbrand 2021-03-22 16:01 ` [PATCH v1 2/3] kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources David Hildenbrand 2021-03-22 16:01 ` David Hildenbrand 2021-03-22 16:11 ` Dan Williams 2021-03-22 16:11 ` Dan Williams 2021-03-22 16:11 ` Dan Williams 2021-03-23 11:08 ` Andy Shevchenko 2021-03-23 11:08 ` Andy Shevchenko 2021-03-23 11:26 ` David Hildenbrand 2021-03-23 11:26 ` David Hildenbrand 2021-03-22 16:02 ` [PATCH v1 3/3] kernel/resource: remove first_lvl / siblings_only logic David Hildenbrand 2021-03-22 16:02 ` David Hildenbrand 2021-03-22 16:12 ` Dan Williams 2021-03-22 16:12 ` Dan Williams 2021-03-22 16:12 ` Dan Williams 2021-03-23 11:11 ` Andy Shevchenko 2021-03-23 11:11 ` Andy Shevchenko 2021-03-23 11:19 ` David Hildenbrand 2021-03-23 11:19 ` David Hildenbrand 2021-03-23 11:05 ` [PATCH v1 0/3] kernel/resource: make walk_system_ram_res() and walk_mem_res() search the whole tree Andy Shevchenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8aa6af09-6f8b-1f50-820f-90eab0993f1c@redhat.com \ --to=david@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bhe@redhat.com \ --cc=bp@alien8.de \ --cc=brijesh.singh@amd.com \ --cc=cai@lca.pw \ --cc=dan.j.williams@intel.com \ --cc=daniel.vetter@ffwll.ch \ --cc=dave.hansen@linux.intel.com \ --cc=dyoung@redhat.com \ --cc=ebiederm@xmission.com \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=keith.busch@intel.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mchehab+huawei@kernel.org \ --cc=mhocko@suse.com \ --cc=mingo@redhat.com \ --cc=osalvador@suse.de \ --cc=tglx@linutronix.de \ --cc=thomas.lendacky@amd.com \ --cc=vgoyal@redhat.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.