All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Brijesh Singh" <brijesh.singh@amd.com>,
	devicetree@vger.kernel.org, "David Airlie" <airlied@linux.ie>,
	linux-pci@vger.kernel.org, "Wei Yang" <richard.weiyang@gmail.com>,
	"Keith Busch" <keith.busch@intel.com>,
	"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Stephen Hemminger" <sthemmin@microsoft.com>,
	"Nicolas Pitre" <nico@linaro.org>,
	"Patrik Jakobsson" <patrik.r.jakobsson@gmail.com>,
	linux-input@vger.kernel.org, "Borislav Petkov" <bp@suse.de>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	linux-nvdimm@lists.01.org, "Jérôme Glisse" <jglisse@redhat.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jonathan Derrick" <jonathan.derrick@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	devel@linuxdriverproject.org
Subject: Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling
Date: Wed, 11 Apr 2018 11:22:20 +0800	[thread overview]
Message-ID: <20180411032220.GA49071@WeideMacBook-Pro.local> (raw)
In-Reply-To: <20180410134416.GM19345@localhost.localdomain>

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote:
>Hi Rob,
>
>Thanks a lot for looking into this and involve Nico to this thread!
>
>On 04/09/18 at 09:49am, Rob Herring wrote:
>> +Nico who has been working on tinification of the kernel.
>> 
>> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He <bhe@redhat.com> wrote:
>> > The struct resource uses singly linked list to link siblings. It's not
>> > easy to do reverse iteration on sibling list. So replace it with list_head.
>> 
>> Why is reverse iteration needed?
>
>This is the explanation I made when Andrew helped to review the v1 post:
>https://lkml.org/lkml/2018/3/23/78
>
>Because we have been using kexec-tools utility to search available
>System RAM space for loading kernel/initrd/purgatory from top to down.
>That is done in user space by searching /proc/iomem. While later added
>kexec_file interface, the searching code happened in kernel, and it
>only search System RAM region bottom up, then take an area in that found
>RAM region from top to down. We need unify these two interfaces on
>behaviour since they are the same on essense from the users' point of
>view, though implementation is different. As you know, the singly linked
>list implementation of the current resource's sibling linking, makes the
>searching from top to down very hard to satisfy people. 
>
>Below is the v1 post, we make an temporary array to copy iomem_resource's
>first level of children, then iterate the array reversedly. Andrew
>suggested me to try list_head after reviewing. In fact we can optimize
>that patch to only copy resource pointer into array, still the way is
>ugly.
>https://lkml.org/lkml/2018/3/21/952
>
>Then Wei pasted a patch he had made as below. He didn't mention if he
>also has requirement on reversed iteration of resource. That is an O(n*n)
>way, from personal feelings, hard to say if it's bettern than v1 post.
>https://lkml.org/lkml/2018/3/24/157

I don't have requirement on reverse iteration of resource structure.

My approach is almost the same as current walk_system_ram_res(). Since each
resource keeps parent, we could get previous resource by search on
res->parent->child.

The complexity of a whole iteration is O(N * W / 2), where N is the number of
resources in the tree and W is the average number of siblings of each
resource.

And this approach doesn't need to change current structure.

>
>That's why I would like to have a try of the list_head linking.
>

-- 
Wei Yang
Help you, Help me
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Wei Yang <richard.weiyang@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Brijesh Singh" <brijesh.singh@amd.com>,
	devicetree@vger.kernel.org, "David Airlie" <airlied@linux.ie>,
	linux-pci@vger.kernel.org, "Wei Yang" <richard.weiyang@gmail.com>,
	"Keith Busch" <keith.busch@intel.com>,
	"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Stephen Hemminger" <sthemmin@microsoft.com>,
	"Nicolas Pitre" <nico@linaro.org>,
	"Patrik Jakobsson" <patrik.r.jakobsson@gmail.com>,
	linux-input@vger.kernel.org, "Borislav Petkov" <bp@suse.de>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	linux-nvdimm@lists.01.org, "Jérôme Glisse" <jglisse@redhat.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Jonathan Derrick" <jonathan.derrick@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	devel@linuxdriverproject.org
Subject: Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling
Date: Wed, 11 Apr 2018 11:22:20 +0800	[thread overview]
Message-ID: <20180411032220.GA49071@WeideMacBook-Pro.local> (raw)
In-Reply-To: <20180410134416.GM19345@localhost.localdomain>

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote:
>Hi Rob,
>
>Thanks a lot for looking into this and involve Nico to this thread!
>
>On 04/09/18 at 09:49am, Rob Herring wrote:
>> +Nico who has been working on tinification of the kernel.
>> 
>> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He <bhe@redhat.com> wrote:
>> > The struct resource uses singly linked list to link siblings. It's not
>> > easy to do reverse iteration on sibling list. So replace it with list_head.
>> 
>> Why is reverse iteration needed?
>
>This is the explanation I made when Andrew helped to review the v1 post:
>https://lkml.org/lkml/2018/3/23/78
>
>Because we have been using kexec-tools utility to search available
>System RAM space for loading kernel/initrd/purgatory from top to down.
>That is done in user space by searching /proc/iomem. While later added
>kexec_file interface, the searching code happened in kernel, and it
>only search System RAM region bottom up, then take an area in that found
>RAM region from top to down. We need unify these two interfaces on
>behaviour since they are the same on essense from the users' point of
>view, though implementation is different. As you know, the singly linked
>list implementation of the current resource's sibling linking, makes the
>searching from top to down very hard to satisfy people. 
>
>Below is the v1 post, we make an temporary array to copy iomem_resource's
>first level of children, then iterate the array reversedly. Andrew
>suggested me to try list_head after reviewing. In fact we can optimize
>that patch to only copy resource pointer into array, still the way is
>ugly.
>https://lkml.org/lkml/2018/3/21/952
>
>Then Wei pasted a patch he had made as below. He didn't mention if he
>also has requirement on reversed iteration of resource. That is an O(n*n)
>way, from personal feelings, hard to say if it's bettern than v1 post.
>https://lkml.org/lkml/2018/3/24/157

I don't have requirement on reverse iteration of resource structure.

My approach is almost the same as current walk_system_ram_res(). Since each
resource keeps parent, we could get previous resource by search on
res->parent->child.

The complexity of a whole iteration is O(N * W / 2), where N is the number of
resources in the tree and W is the average number of siblings of each
resource.

And this approach doesn't need to change current structure.

>
>That's why I would like to have a try of the list_head linking.
>

-- 
Wei Yang
Help you, Help me
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: Wei Yang <richard.weiyang@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Rob Herring" <robh+dt@kernel.org>,
	"Nicolas Pitre" <nico@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Patrik Jakobsson" <patrik.r.jakobsson@gmail.com>,
	"David Airlie" <airlied@linux.ie>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	"Stephen Hemminger" <sthemmin@microsoft.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Keith Busch" <keith.busch@intel.com>,
	"Jonathan Derrick" <jonathan.derrick@intel.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Brijesh Singh" <brijesh.singh@amd.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
	"Wei Yang" <richard.weiyang@gmail.com>,
	devel@linuxdriverproject.org, linux-input@vger.kernel.org,
	linux-nvdimm@lists.01.org, devicetree@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling
Date: Wed, 11 Apr 2018 11:22:20 +0800	[thread overview]
Message-ID: <20180411032220.GA49071@WeideMacBook-Pro.local> (raw)
In-Reply-To: <20180410134416.GM19345@localhost.localdomain>

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote:
>Hi Rob,
>
>Thanks a lot for looking into this and involve Nico to this thread!
>
>On 04/09/18 at 09:49am, Rob Herring wrote:
>> +Nico who has been working on tinification of the kernel.
>> 
>> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He <bhe@redhat.com> wrote:
>> > The struct resource uses singly linked list to link siblings. It's not
>> > easy to do reverse iteration on sibling list. So replace it with list_head.
>> 
>> Why is reverse iteration needed?
>
>This is the explanation I made when Andrew helped to review the v1 post:
>https://lkml.org/lkml/2018/3/23/78
>
>Because we have been using kexec-tools utility to search available
>System RAM space for loading kernel/initrd/purgatory from top to down.
>That is done in user space by searching /proc/iomem. While later added
>kexec_file interface, the searching code happened in kernel, and it
>only search System RAM region bottom up, then take an area in that found
>RAM region from top to down. We need unify these two interfaces on
>behaviour since they are the same on essense from the users' point of
>view, though implementation is different. As you know, the singly linked
>list implementation of the current resource's sibling linking, makes the
>searching from top to down very hard to satisfy people. 
>
>Below is the v1 post, we make an temporary array to copy iomem_resource's
>first level of children, then iterate the array reversedly. Andrew
>suggested me to try list_head after reviewing. In fact we can optimize
>that patch to only copy resource pointer into array, still the way is
>ugly.
>https://lkml.org/lkml/2018/3/21/952
>
>Then Wei pasted a patch he had made as below. He didn't mention if he
>also has requirement on reversed iteration of resource. That is an O(n*n)
>way, from personal feelings, hard to say if it's bettern than v1 post.
>https://lkml.org/lkml/2018/3/24/157

I don't have requirement on reverse iteration of resource structure.

My approach is almost the same as current walk_system_ram_res(). Since each
resource keeps parent, we could get previous resource by search on
res->parent->child.

The complexity of a whole iteration is O(N * W / 2), where N is the number of
resources in the tree and W is the average number of siblings of each
resource.

And this approach doesn't need to change current structure.

>
>That's why I would like to have a try of the list_head linking.
>

-- 
Wei Yang
Help you, Help me

  reply	other threads:[~2018-04-11  3:22 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-08  2:47 [PATCH v2 0/3] resource: Use list_head to link sibling resource Baoquan He
2018-04-08  2:47 ` [PATCH v2 1/3] " Baoquan He
2018-04-08  2:47   ` Baoquan He
2018-04-08  2:47   ` Baoquan He
2018-04-08  2:47   ` Baoquan He
2018-04-08  4:12   ` kbuild test robot
2018-04-08  4:12     ` kbuild test robot
2018-04-08  4:12     ` kbuild test robot
2018-04-08  4:12     ` kbuild test robot
2018-04-08  9:09     ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  5:55   ` kbuild test robot
2018-04-08  5:55     ` kbuild test robot
2018-04-08  5:55     ` kbuild test robot
2018-04-08  5:55     ` kbuild test robot
2018-04-08  9:09     ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-09  9:08   ` [PATCH v3 1/3] resource: Use list_head to link resource sibling Baoquan He
2018-04-09  9:08     ` Baoquan He
2018-04-09  9:08     ` Baoquan He
2018-04-09 14:49     ` Rob Herring
2018-04-09 14:49       ` Rob Herring
2018-04-09 14:49       ` Rob Herring
2018-04-09 16:05       ` Nicolas Pitre
2018-04-09 16:05         ` Nicolas Pitre
2018-04-09 16:05         ` Nicolas Pitre
2018-04-09 16:05         ` Nicolas Pitre
2018-04-10 13:44       ` Baoquan He
2018-04-10 13:44         ` Baoquan He
2018-04-10 13:44         ` Baoquan He
2018-04-10 13:44         ` Baoquan He
2018-04-11  3:22         ` Wei Yang [this message]
2018-04-11  3:22           ` Wei Yang
2018-04-11  3:22           ` Wei Yang
2018-04-09 15:38     ` Dan Williams
2018-04-09 15:38       ` Dan Williams
2018-04-09 15:38       ` Dan Williams
2018-04-10  2:10       ` Baoquan He
2018-04-10  2:10         ` Baoquan He
2018-04-10  2:10         ` Baoquan He
2018-04-10  2:10         ` Baoquan He
2018-04-10  2:34         ` Dan Williams
2018-04-10  2:34           ` Dan Williams
2018-04-10  2:34           ` Dan Williams
2018-04-10  2:34           ` Dan Williams
2018-04-10  2:49           ` Baoquan He
2018-04-10  2:49             ` Baoquan He
2018-04-10  2:49             ` Baoquan He
2018-04-10  2:49             ` Baoquan He
2018-04-08  2:47 ` [PATCH v2 2/3] resource: add walk_system_ram_res_rev() Baoquan He
2018-04-08  2:47 ` [PATCH v2 3/3] kexec_file: Load kernel at top of system RAM if required Baoquan He
2018-04-08  2:47   ` Baoquan He

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=20180411032220.GA49071@WeideMacBook-Pro.local \
    --to=richard.weiyang@gmail.com \
    --cc=airlied@linux.ie \
    --cc=baiyaowei@cmss.chinamobile.com \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=devel@linuxdriverproject.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=haiyangz@microsoft.com \
    --cc=jglisse@redhat.com \
    --cc=jonathan.derrick@intel.com \
    --cc=keith.busch@intel.com \
    --cc=kys@microsoft.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=nico@linaro.org \
    --cc=patrik.r.jakobsson@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    /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: link
Be 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.