All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@mips.com>
To: James Hogan <jhogan@kernel.org>
Cc: Huacai Chen <chenhc@lemote.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"Steven J . Hill" <Steven.Hill@cavium.com>,
	<linux-mips@linux-mips.org>, Fuxin Zhang <zhangfx@lemote.com>,
	Zhangjin Wu <wuzhangjin@gmail.com>
Subject: Re: [PATCH V2 08/12] MIPS: Align kernel load address to 64KB
Date: Tue, 20 Feb 2018 22:14:39 +0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1802202206490.3553@tp.orcam.me.uk> (raw)
In-Reply-To: <20180219230719.GC6245@saruman>

On Mon, 19 Feb 2018, James Hogan wrote:

> > KEXEC assume kernel align to PAGE_SIZE, and 64KB is the largest
> > PAGE_SIZE.
> 
> Please expand, maybe referring to sanity_check_segment_list() which does
> the actual check. Maybe something like this:
> 
>  Kexec needs the new kernel's load address to be aligned on a page
>  boundary (see sanity_check_segment_list()), but on MIPS the default
>  vmlinuz load address is only explicitly aligned to 16 bytes.
> 
>  Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
>  the alignment calculated by calc_vmlinuz_load_addr to 64KB.

 But why does it have to be hardcoded?  Shouldn't it be inherited from 
the image being loaded?  I'm missing bits of context here, but that 
would be either CONFIG_PAGE_SIZE_* settings or the ELF program header's 
`p_align' value, depending on how this code operates.  Wasting say 60kB 
of memory on smaller systems due to excessive alignment might not be a 
good idea.

  Maciej

WARNING: multiple messages have this Message-ID (diff)
From: "Maciej W. Rozycki" <macro@mips.com>
To: James Hogan <jhogan@kernel.org>
Cc: Huacai Chen <chenhc@lemote.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"Steven J . Hill" <Steven.Hill@cavium.com>,
	linux-mips@linux-mips.org, Fuxin Zhang <zhangfx@lemote.com>,
	Zhangjin Wu <wuzhangjin@gmail.com>
Subject: Re: [PATCH V2 08/12] MIPS: Align kernel load address to 64KB
Date: Tue, 20 Feb 2018 22:14:39 +0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1802202206490.3553@tp.orcam.me.uk> (raw)
Message-ID: <20180220221439.l1C6Cp-9D_M6r7XYdnCd8QU-7ZIlT0q7dCX71p7q-is@z> (raw)
In-Reply-To: <20180219230719.GC6245@saruman>

On Mon, 19 Feb 2018, James Hogan wrote:

> > KEXEC assume kernel align to PAGE_SIZE, and 64KB is the largest
> > PAGE_SIZE.
> 
> Please expand, maybe referring to sanity_check_segment_list() which does
> the actual check. Maybe something like this:
> 
>  Kexec needs the new kernel's load address to be aligned on a page
>  boundary (see sanity_check_segment_list()), but on MIPS the default
>  vmlinuz load address is only explicitly aligned to 16 bytes.
> 
>  Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
>  the alignment calculated by calc_vmlinuz_load_addr to 64KB.

 But why does it have to be hardcoded?  Shouldn't it be inherited from 
the image being loaded?  I'm missing bits of context here, but that 
would be either CONFIG_PAGE_SIZE_* settings or the ELF program header's 
`p_align' value, depending on how this code operates.  Wasting say 60kB 
of memory on smaller systems due to excessive alignment might not be a 
good idea.

  Maciej

  reply	other threads:[~2018-02-20 22:15 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-27  3:12 [PATCH V2 00/12] MIPS: Loongson: new features and improvements Huacai Chen
2018-01-27  3:12 ` [PATCH V2 01/12] MIPS: Loongson: Add Loongson-3A R3.1 basic support Huacai Chen
2018-01-27  3:12 ` [PATCH V2 02/12] MIPS: Loongson64: Define and use some CP0 registers Huacai Chen
2018-02-15 11:36   ` James Hogan
2018-01-27  3:12 ` [PATCH V2 03/12] MIPS: Loongson-3: Enable Store Fill Buffer at runtime Huacai Chen
2018-02-15 12:43   ` James Hogan
2018-01-27  3:19 ` [PATCH V2 04/12] MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3 Huacai Chen
2018-02-19 22:19   ` James Hogan
2018-01-27  3:20 ` [PATCH V2 05/12] MIPS: Loongson fix name confict - MEM_RESERVED Huacai Chen
2018-01-27  3:21 ` [PATCH V2 06/12] MIPS: Ensure pmd_present() returns false after pmd_mknotpresent() Huacai Chen
2018-01-27  3:22 ` [PATCH V2 07/12] MIPS: Add __cpu_full_name[] to make CPU names more human-readable Huacai Chen
2018-01-27  3:22   ` [PATCH V2 08/12] MIPS: Align kernel load address to 64KB Huacai Chen
2018-02-19 23:07     ` James Hogan
2018-02-20 22:14       ` Maciej W. Rozycki [this message]
2018-02-20 22:14         ` Maciej W. Rozycki
2018-02-20 22:25         ` James Hogan
2018-02-20 22:25           ` James Hogan
2018-02-20 22:53           ` Maciej W. Rozycki
2018-02-20 22:53             ` Maciej W. Rozycki
2018-02-20 22:58             ` James Hogan
2018-02-20 22:58               ` James Hogan
2018-02-20 23:38               ` Maciej W. Rozycki
2018-02-20 23:38                 ` Maciej W. Rozycki
2018-02-21 11:13                 ` James Hogan
2018-02-21 11:13                   ` James Hogan
2018-02-26 12:41                   ` Maciej W. Rozycki
2018-02-26 12:41                     ` Maciej W. Rozycki
2018-01-27  3:22   ` [PATCH V2 09/12] MIPS: Loongson: Add kexec/kdump support Huacai Chen
2018-02-19 23:54     ` James Hogan
2018-01-27  3:22 ` [PATCH V2 10/12] MIPS: Loongson: Make CPUFreq usable for Loongson-3 Huacai Chen
2018-01-27  3:23   ` [PATCH V2 11/12] MIPS: Loongson-3: Fix CPU UART irq delivery problem Huacai Chen
2018-02-20 21:49     ` James Hogan
2018-01-27  3:23   ` [PATCH V2 12/12] MIPS: Loongson: Introduce and use WAR_LLSC_MB Huacai Chen
2018-02-20 22:21     ` James Hogan
2018-02-21 10:09       ` Maciej W. Rozycki
2018-02-21 10:09         ` Maciej W. Rozycki
2018-02-21 11:43         ` James Hogan
2018-02-20 21:42   ` [PATCH V2 10/12] MIPS: Loongson: Make CPUFreq usable for Loongson-3 James Hogan
2018-02-15 11:05 ` [PATCH V2 00/12] MIPS: Loongson: new features and improvements James Hogan
2018-02-28  2:23   ` Huacai Chen
2018-02-28 10:03     ` James Hogan
2018-03-01  2:35       ` Huacai Chen

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=alpine.DEB.2.00.1802202206490.3553@tp.orcam.me.uk \
    --to=macro@mips.com \
    --cc=Steven.Hill@cavium.com \
    --cc=chenhc@lemote.com \
    --cc=jhogan@kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=wuzhangjin@gmail.com \
    --cc=zhangfx@lemote.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.