linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@lists.ozlabs.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>, Greg Kurz <groug@kaod.org>,
	Balbir Singh <bsingharora@gmail.com>,
	Thomas Huth <thuth@redhat.com>,
	Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
	slof@lists.ozlabs.org
Subject: Re: [PATCH kernel] RFC: prom_init: Fetch flatten device tree from the system firmware
Date: Mon, 16 Oct 2017 17:22:55 +1100	[thread overview]
Message-ID: <00ec0e99-45dd-dbe0-d75f-4413253e8093@ozlabs.ru> (raw)
In-Reply-To: <20171016061125.GD2776@umbus.fritz.box>


[-- Attachment #1.1: Type: text/plain, Size: 3313 bytes --]

On 16/10/17 17:11, David Gibson wrote:
> On Mon, Oct 16, 2017 at 04:49:17PM +1100, Alexey Kardashevskiy wrote:
>> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
>> about 8.5sec to read the entire device tree. Some explanation can be
>> found here: https://patchwork.ozlabs.org/patch/826124/ but mostly it is
>> because the kernel traverses the tree twice and it calls "getprop" for
>> each properly which is really SLOF as it searches from the linked list
>> beginning every time.
>>
>> Since SLOF has just learned to build FDT and this takes less than 0.5sec
>> for such a big guest, this makes use of the proposed client interface
>> method - "fdt-fetch".
>>
>> If "fdt-fetch" is not available, the old method is used.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> 
> I like the concept, few details though..
> 
>> ---
>>  arch/powerpc/kernel/prom_init.c | 26 ++++++++++++++++++++++++++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
>> index 02190e90c7ae..daa50a153737 100644
>> --- a/arch/powerpc/kernel/prom_init.c
>> +++ b/arch/powerpc/kernel/prom_init.c
>> @@ -2498,6 +2498,31 @@ static void __init flatten_device_tree(void)
>>  		prom_panic("Can't allocate initial device-tree chunk\n");
>>  	mem_end = mem_start + room;
>>  
>> +	if (!call_prom_ret("fdt-fetch", 2, 1, NULL, mem_start,
>> +			   room - sizeof(mem_reserve_map))) {
>> +		u32 size;
>> +
>> +		hdr = (void *) mem_start;
>> +
>> +		/* Fixup the boot cpuid */
>> +		hdr->boot_cpuid_phys = cpu_to_be32(prom.cpu);
> 
> If SLOF is generating a tree it really should get this header field
> right as well.


Ah, I did not realize it is just a phandle from /chosen/cpu. Will fix.


> 
>> +		/* Append the reserved map to the end of the blob */
>> +		hdr->off_mem_rsvmap = hdr->totalsize;
>> +		size = be32_to_cpu(hdr->totalsize);
>> +		rsvmap = (void *) hdr + size;
>> +		hdr->totalsize = cpu_to_be32(size + sizeof(mem_reserve_map));
>> +		memcpy(rsvmap, mem_reserve_map, sizeof(mem_reserve_map));
> 
> .. and the reserve map for that matter.  I don't really understand
> what you're doing here. 

? Get the blob, increase the FDT size by sizeof(mem_reserve_map), fix up
totalsize and off_mem_rsvmap, copy mem_reserve_map to the end of the blob
(the actual order is slightly different, may be a bit confusing).

Asking SLOF to reserve the space seems to be unnecessary complication of
the interface - SLOF does not provide any reserved memory records.

> Note also that the reserve map is required to
> be 8-byte aligned, which totalsize might not be.

Ah, good point.


> 
>> +		/* Store the DT address */
>> +		dt_header_start = mem_start;
>> +
>> +#ifdef DEBUG_PROM
>> +		prom_printf("Fetched DTB: %d bytes to @%x\n", size, mem_start);
>> +#endif
>> +		goto print_exit;
>> +	}
>> +
>>  	/* Get root of tree */
>>  	root = call_prom("peer", 1, 1, (phandle)0);
>>  	if (root == (phandle)0)
>> @@ -2548,6 +2573,7 @@ static void __init flatten_device_tree(void)
>>  	/* Copy the reserve map in */
>>  	memcpy(rsvmap, mem_reserve_map, sizeof(mem_reserve_map));
>>  
>> +print_exit:
>>  #ifdef DEBUG_PROM
>>  	{
>>  		int i;
> 


-- 
Alexey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 839 bytes --]

  reply	other threads:[~2017-10-16  6:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-16  5:49 [PATCH kernel] RFC: prom_init: Fetch flatten device tree from the system firmware Alexey Kardashevskiy
2017-10-16  6:11 ` David Gibson
2017-10-16  6:22   ` Alexey Kardashevskiy [this message]
2017-10-16  6:46     ` David Gibson
2017-10-16  7:07       ` Alexey Kardashevskiy
2017-10-16  9:05         ` David Gibson
2017-10-16 10:20         ` Segher Boessenkool
2017-10-16 11:08           ` Alexey Kardashevskiy
2017-10-16 11:59 ` Michael Ellerman

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=00ec0e99-45dd-dbe0-d75f-4413253e8093@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=slof@lists.ozlabs.org \
    --cc=thuth@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).