Re: [PATCH v7 3/4] lib/cmdline.c Remove quotes symmetrically.

[Baoquan He]

On 08/17/17 at 10:14pm, Michal Suchanek wrote:
> Remove quotes from argument value only if there is qoute on both sides.
> 
> Signed-off-by: Michal Suchanek 

Sounds reasonable. Just for curiosity, do we have chance to pass in
option with a single '"'?

> ---
>  arch/powerpc/kernel/fadump.c | 6 ++
>  lib/cmdline.c| 7 ++-
>  2 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index a1614d9b8a21..d7da4ce9f7ae 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -489,10 +489,8 @@ static void __init fadump_update_params(struct 
> param_info *param_info,
>   *tgt++ = ' ';
>  
>   /* next_arg removes one leading and one trailing '"' */
> - if (*tgt == '"')
> - shortening += 1;
> - if (*(tgt + vallen + shortening) == '"')
> - shortening += 1;
> + if ((*tgt == '"') && (*(tgt + vallen + shortening) == '"'))
> + shortening += 2;
>  
>   /* remove one leading and one trailing quote if both are present */
>   if ((val[0] == '"') && (val[vallen - 1] == '"')) {
> diff --git a/lib/cmdline.c b/lib/cmdline.c
> index 4c0888c4a68d..01e701b2afe8 100644
> --- a/lib/cmdline.c
> +++ b/lib/cmdline.c
> @@ -227,14 +227,11 @@ char *next_arg(char *args, char **param, char **val)
>   *val = args + equals + 1;
>  
>   /* Don't include quotes in value. */
> - if (**val == '"') {
> + if ((**val == '"') && (args[i-1] == '"')) {
>   (*val)++;
> - if (args[i-1] == '"')
> - args[i-1] = '\0';
> + args[i-1] = '\0';
>   }
>   }
> - if (quoted && args[i-1] == '"')
> - args[i-1] = '\0';
>  
>   if (args[i]) {
>   args[i] = '\0';
> -- 
> 2.10.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] Documentation/kernel-parameters.txt: Update 'memmap=' option description

[Baoquan He]

In commit:

  9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")

... 'memmap=' was changed to adopt multiple, comma delimited values in a
single entry, so update the related description.

In the special case of only specifying size value without an offset,
like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
it too here.

Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
as suggested by the documentation, "memmap=100MG" gets passed to the kernel.

Clarify all this.

Signed-off-by: Baoquan He <b...@redhat.com>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelg...@google.com>
Cc: Mauro Carvalho Chehab <mche...@kernel.org>
Cc: linux-doc@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 986e443..d518144 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2097,6 +2097,12 @@
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
+   If @ss[KMG] is omitted, it equals to mem=nn[KMG]
+   which limits max address as nn[KMG].
+   Multiple different options can be put into one entry
+   with comma delimited to save space:
+   Example:
+   memmap=100M@2G,100M#3G,1G!1024G
 
memmap=nn[KMG]#ss[KMG]
[KNL,ACPI] Mark specific memory as ACPI data.
@@ -2109,6 +2115,9 @@
 memmap=64K$0x1869
 or
 memmap=0x1$0x1869
+   Some bootloaders may need escape character before '$',
+   like in grub2, otherwise '$' and the following number
+   will be eaten.
 
memmap=nn[KMG]!ss[KMG]
[KNL,X86] Mark specific memory as protected.
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] Documentation/kernel-parameters.txt: Update 'memmap=' option description

[Baoquan He]

On 04/24/17 at 11:53am, Dou Liyang wrote:
> 
> 
> At 04/24/2017 10:40 AM, Baoquan He wrote:
> > In commit:
> > 
> >   9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")
> > 
> > ... 'memmap=' was changed to adopt multiple, comma delimited values in a
> > single entry, so update the related description.
> > 
> > In the special case of only specifying size value without an offset,
> > like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
> > it too here.
> > 
> > Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
> > before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
> > as suggested by the documentation, "memmap=100MG" gets passed to the kernel.
> > 
> > Clarify all this.
> > 
> > Signed-off-by: Baoquan He <b...@redhat.com>
> > Cc: Jonathan Corbet <cor...@lwn.net>
> > Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.com>
> > Cc: Andrew Morton <a...@linux-foundation.org>
> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > Cc: Bjorn Helgaas <bhelg...@google.com>
> > Cc: Mauro Carvalho Chehab <mche...@kernel.org>
> > Cc: linux-doc@vger.kernel.org
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 986e443..4054328 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2097,6 +2097,12 @@
> > memmap=nn[KMG]@ss[KMG]
> > [KNL] Force usage of a specific region of memory.
> > Region of memory to be used is from ss to ss+nn.
> > +   If @ss[KMG] is ommited, it equals to mem=nn[KMG]
> 
> s/ommited/omitted/

Right, thanks. Will see if there's other comment and update.

> 
> > +   which limits max address as nn[KMG].
> > +   Multiple different options can be put into one entry
> > +   with comma delimited to save space:
> > +   Example:
> > +   memmap=100M@2G,100M#3G,1G!1024G
> > 
> > memmap=nn[KMG]#ss[KMG]
> > [KNL,ACPI] Mark specific memory as ACPI data.
> > @@ -2109,6 +2115,9 @@
> >  memmap=64K$0x1869
> >  or
> >  memmap=0x1$0x1869
> > +   Some bootloaders may need escape character before '$',
> > +   like in grub2, otherwise '$' and the following number
> > +   will be eaten.
> > 
> > memmap=nn[KMG]!ss[KMG]
> > [KNL,X86] Mark specific memory as protected.
> > 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] Documentation/kernel-parameters.txt: Update 'memmap=' option description

[Baoquan He]

In commit:

  9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")

... 'memmap=' was changed to adopt multiple, comma delimited values in a
single entry, so update the related description.

In the special case of only specifying size value without an offset,
like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
it too here.

Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
as suggested by the documentation, "memmap=100MG" gets passed to the kernel.

Clarify all this.

Signed-off-by: Baoquan He <b...@redhat.com>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelg...@google.com>
Cc: Mauro Carvalho Chehab <mche...@kernel.org>
Cc: linux-doc@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 986e443..4054328 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2097,6 +2097,12 @@
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
+   If @ss[KMG] is ommited, it equals to mem=nn[KMG]
+   which limits max address as nn[KMG].
+   Multiple different options can be put into one entry
+   with comma delimited to save space:
+   Example:
+   memmap=100M@2G,100M#3G,1G!1024G
 
memmap=nn[KMG]#ss[KMG]
[KNL,ACPI] Mark specific memory as ACPI data.
@@ -2109,6 +2115,9 @@
 memmap=64K$0x1869
 or
 memmap=0x1$0x1869
+   Some bootloaders may need escape character before '$',
+   like in grub2, otherwise '$' and the following number
+   will be eaten.
 
memmap=nn[KMG]!ss[KMG]
[KNL,X86] Mark specific memory as protected.
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] doc: Update description about memmap option in kernel-parameter.txt

[Baoquan He]

In commit 9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")
memmap was changed to adopt multiple values with comma delimited in
one entry, so update the related description.

And if only specify size value without offset, like memmap=nn[KMG],
memmap behaves equal to mem=nn[KMG], update it too here.

And for memmap=nn[KMG]$ss[KMG], escape character need be added before
'$' for some bootloaders. E.g in grub2, if specified memmap=100M$5G,
actually it passed memmap=100MG to kernel.

Signed-off-by: Baoquan He <b...@redhat.com>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelg...@google.com>
Cc: Mauro Carvalho Chehab <mche...@kernel.org>
Cc: linux-doc@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index facc20a..6789262 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2112,6 +2112,12 @@
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
+   If @ss[KMG] is ommited, it equals to mem=nn[KMG]
+   which limits max address as nn[KMG].
+   Multiple different options can be put into one entry
+   with comma delimited to save space:
+   Example:
+   memmap=100M@2G,100M#3G,1G!1024G
 
memmap=nn[KMG]#ss[KMG]
[KNL,ACPI] Mark specific memory as ACPI data.
@@ -2124,6 +2130,9 @@
 memmap=64K$0x1869
 or
 memmap=0x1$0x1869
+   Some bootloaders may need escape character before '$',
+   like in grub2, otherwise '$' and the following number
+   will be eaten.
 
memmap=nn[KMG]!ss[KMG]
[KNL,X86] Mark specific memory as protected.
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 RESEND 0/3] Documentation: Add description of enable multi-cpus support for kdump

[Baoquan He]

On 09/20/16 at 06:03pm, Jonathan Corbet wrote:
> On Mon, 19 Sep 2016 13:59:46 +0800
> Baoquan He <b...@redhat.com> wrote:
> 
> > This is v10 post. In this patchset patch 1/3 is added to give more details
> > about nr_cpus and maxcpus in kernel-parameters.txt. This is suggested by
> > Jonathan since the description of them is unclear so that people can't see
> > what's the exact difference between them. Otherwise no big further change
> > for 2/3 and 3/3 which comprise the old post.
> 
> So somehow I'd applied 1/3 a while back, but not the other two.  All three
> are in the docs tree now, thanks.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 RESEND 2/3] Documentation: kdump: Remind user of nr_cpus

[Baoquan He]

From: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>
Acked-by: Baoquan He <b...@redhat.com>
Acked-by: Xunlei Pang <xp...@redhat.com>
---
 Documentation/kdump/kdump.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..f7ef340 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you had better replace it with
+  nr_cpus to save memory if supported by the current ARCH, such as x86.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 RESEND 1/3] docs: kernel-parameter : Improve the description of nr_cpus and maxcpus

[Baoquan He]

>From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in ARCH. The reason
is nr_cpus is used to limit the max number of possible cpu in system,
the sum of already plugged cpus and hot plug cpus can't exceed its
value. However maxcpus is used to limit how many cpus are allowed to
be brought up during bootup.

Signed-off-by: Baoquan He <b...@redhat.com>
---
 Documentation/kernel-parameters.txt | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index a4f4d69..98d6406 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
than or equal to this physical address is ignored.
 
maxcpus=[SMP] Maximum number of processors that an SMP kernel
-   should make use of.  maxcpus=n : n >= 0 limits the
-   kernel to using 'n' processors.  n=0 is a special case,
-   it is equivalent to "nosmp", which also disables
-   the IO APIC.
+   will bring up during bootup.  maxcpus=n : n >= 0 limits
+   the kernel to bring up 'n' processors. Surely after
+   bootup you can bring up the other plugged cpu by 
executing
+   "echo 1 > /sys/devices/system/cpu/cpuX/online". So 
maxcpus
+   only takes effect during system bootup.
+   While n=0 is a special case, it is equivalent to 
"nosmp",
+   which also disables the IO APIC.
 
max_loop=   [LOOP] The number of loop block devices that get
(loop.max_loop) unconditionally pre-created at init time. The default
@@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
nr_cpus=[SMP] Maximum number of processors that an SMP kernel
could support.  nr_cpus=n : n >= 1 limits the kernel to
-   supporting 'n' processors. Later in runtime you can not
-   use hotplug cpu feature to put more cpu back to online.
-   just like you compile the kernel NR_CPUS=n
+   support 'n' processors. It could be larger than the
+   number of already plugged CPU during bootup, later in
+   runtime you can physically add extra cpu until it 
reaches
+   n. So during boot up some boot time memory for per-cpu
+   variables need be pre-allocated for later physical cpu
+   hot plugging.
 
nr_uarts=   [SERIAL] maximum number of UARTs to be registered.
 
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 RESEND 3/3] Documentation: kdump: Add description of enable multi-cpus support

[Baoquan He]

From: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>

Multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>
Acked-by: Baoquan He <b...@redhat.com>
Acked-by: Xunlei Pang <xp...@redhat.com>
---
 Documentation/kdump/kdump.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index f7ef340..b0eb27b 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you had better replace it with
   nr_cpus to save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up an
+  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
+  options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 3/3] Documentation: kdump: add description of enable multi-cpus support

[Baoquan He]

On 09/19/16 at 12:01pm, Baoquan He wrote:
> From: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>
> 
> Multi-cpu support is useful to improve the performance of kdump in
> some cases. So add the description of enable multi-cpu support in
> dump-capture kernel.
> 
> Signed-off-by: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>
> Acked-by: Baoquan He <b...@redhat.com>
> Acked-by: Xunlei Pang <xp...@redhat.com>
> Signed-off-by: Baoquan He <b...@redhat.com>

Oh, sorry. My git config caused this Signed-off-by adding automatically.
Will resend. Nack this patchset.

> ---
>  Documentation/kdump/kdump.txt | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index f7ef340..b0eb27b 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
>Note, though maxcpus always works, you had better replace it with
>nr_cpus to save memory if supported by the current ARCH, such as x86.
>  
> +* You should enable multi-cpu support in dump-capture kernel if you intend
> +  to use multi-thread programs with it, such as parallel dump feature of
> +  makedumpfile. Otherwise, the multi-thread program may have a great
> +  performance degradation. To enable multi-cpu support, you should bring up 
> an
> +  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
> +  options while loading it.
> +
>  * For s390x there are two kdump modes: If a ELF header is specified with
>the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
>is done on all other architectures. If no elfcorehdr= kernel parameter is
> -- 
> 2.5.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 1/3] docs: kernel-parameter : Improve the description of nr_cpus and maxcpus

[Baoquan He]

>From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in ARCH. The reason
is nr_cpus is used to limit the max number of possible cpu in system,
the sum of already plugged cpus and hot plug cpus can't exceed its
value. However maxcpus is used to limit how many cpus are allowed to
be brought up during bootup.

Signed-off-by: Baoquan He <b...@redhat.com>
---
 Documentation/kernel-parameters.txt | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index a4f4d69..98d6406 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
than or equal to this physical address is ignored.
 
maxcpus=[SMP] Maximum number of processors that an SMP kernel
-   should make use of.  maxcpus=n : n >= 0 limits the
-   kernel to using 'n' processors.  n=0 is a special case,
-   it is equivalent to "nosmp", which also disables
-   the IO APIC.
+   will bring up during bootup.  maxcpus=n : n >= 0 limits
+   the kernel to bring up 'n' processors. Surely after
+   bootup you can bring up the other plugged cpu by 
executing
+   "echo 1 > /sys/devices/system/cpu/cpuX/online". So 
maxcpus
+   only takes effect during system bootup.
+   While n=0 is a special case, it is equivalent to 
"nosmp",
+   which also disables the IO APIC.
 
max_loop=   [LOOP] The number of loop block devices that get
(loop.max_loop) unconditionally pre-created at init time. The default
@@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
nr_cpus=[SMP] Maximum number of processors that an SMP kernel
could support.  nr_cpus=n : n >= 1 limits the kernel to
-   supporting 'n' processors. Later in runtime you can not
-   use hotplug cpu feature to put more cpu back to online.
-   just like you compile the kernel NR_CPUS=n
+   support 'n' processors. It could be larger than the
+   number of already plugged CPU during bootup, later in
+   runtime you can physically add extra cpu until it 
reaches
+   n. So during boot up some boot time memory for per-cpu
+   variables need be pre-allocated for later physical cpu
+   hot plugging.
 
nr_uarts=   [SERIAL] maximum number of UARTs to be registered.
 
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 2/3] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

From: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>
Acked-by: Baoquan He <b...@redhat.com>
Acked-by: Xunlei Pang <xp...@redhat.com>
Signed-off-by: Baoquan He <b...@redhat.com>
---
 Documentation/kdump/kdump.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..f7ef340 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you had better replace it with
+  nr_cpus to save memory if supported by the current ARCH, such as x86.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 3/3] Documentation: kdump: add description of enable multi-cpus support

[Baoquan He]

From: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>

Multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian <zhouwj-f...@cn.fujitsu.com>
Acked-by: Baoquan He <b...@redhat.com>
Acked-by: Xunlei Pang <xp...@redhat.com>
Signed-off-by: Baoquan He <b...@redhat.com>
---
 Documentation/kdump/kdump.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index f7ef340..b0eb27b 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you had better replace it with
   nr_cpus to save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up an
+  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
+  options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 0/3] Documentation: add description of enable multi-cpus support for kdump

[Baoquan He]

This is v10 post. In this patchset patch 1/3 is added to give more details
about nr_cpus and maxcpus in kernel-parameters.txt. This is suggested by
Jonathan since the description of them is unclear so that people can't see
what's the exact difference between them. Otherwise no big further change
for 2/3 and 3/3 which comprise the old post.

Please access below link to check the previous changelog.
https://lkml.org/lkml/2016/8/17/646

Baoquan He (1):
  docs: kernel-parameter : Improve the description of nr_cpus and
maxcpus

Zhou Wenjian (2):
  Documentation: kdump: remind user of nr_cpus
  Documentation: kdump: add description of enable multi-cpus support

 Documentation/kdump/kdump.txt   |  9 +
 Documentation/kernel-parameters.txt | 20 +---
 2 files changed, 22 insertions(+), 7 deletions(-)

-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/26/16 at 08:45am, "Zhou, Wenjian/周文剑" wrote:
> Hi Baoquan,
> 
> Sorry, I misunderstood it before.
> Thanks for your detailed explanation.
> 
> Hi Jon and Baoquan, I'm confused about how to adjust the kdump.txt.
> Does the patch set v9 still OK?

Yeah, I think it's OK. Let's wait for Jon's feekback.

> 
> -- 
> Thanks
> Zhou
> 
> On 08/24/2016 01:06 PM, Baoquan He wrote:
> >On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> >>On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >>>On Fri, 19 Aug 2016 08:33:21 +0800
> >>>"Zhou, Wenjian/周文剑" <zhouwj-f...@cn.fujitsu.com> wrote:
> >>>
> >>>>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>>>I think it is a good choice to describe it in kernel-parameters.txt.
> >>>>
> >>>>Then, only two things need to be done I think.
> >>>>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>>>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>>>
> >>>>How do you think?
> >>>
> >>>That is not quite what I had in mind, sorry.  What I would really like to
> >>>see in kernel-parameters.txt is an explanation of how those two parameters
> >>>differ - what do they do differently and how should a user choose one over
> >>>the other?  What we have now offers no guidance in that matter.
> >>>
> >>
> >>I thought about it. I think user may not need this.
> >>What user really want to know is how to choose.
> >>And it is also not a hard work. If nr_cpus is not supported by the ARCH, 
> >>use maxcpus.
> >>Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be 
> >>supported
> >>by some ARCHes.
> >
> >I think Jon is suggesting that a note can be added into
> >kernel-parameter.txt to tell what's the difference between nr_cpus and
> >max_cpus. I checked code and discussed within our kdump team, max_cpus
> >is used to limit how many 'present' cpus are allowed to be brought up
> >during system bootup, while nr_cpus is used to set the upper limit of
> >'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
> >cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
> >plug, means during bootup you want to bring up 4 present cpus, but
> >later you could physically hot plug 4 others. Because of attribute of
> >some static percpu variables, we need pre-allocate memory for all
> >possible cpus though some of them may not be really used if no extra
> >cpu physically hot plugged after system bootup.
> >
> >Hence for kdump kernel, people never want to do a cpu hot plug in there.
> >That's why we want to use nr_cpus to limit the number of possible cpu to
> >save memory. E.g still on my laptop, if I want to do a kdump, the number
> >of possible cpu is still 8, but you may want to use only 1 cpu to dump,
> >maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
> >nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
> >memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
> >is much better. While with specifying max_cpus=1, the number of possible
> >cpu is still 8. That's the reason. On x86_64 and s390, there's another
> >kernel para "possible_cpus=xx" which can be used to set possible cpus for
> >cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
> >I am not very sure why this is introduced, number of possible cpu is
> >decided by the min value of nr_cpus= and possible_cpus=.
> >
> >nr_cpus and maxcpus might not be very clear to people which are
> >described in Documentation/kernel-parameters.txt.
> >
> >Hi Jon, do you think change as below is OK to you?
> >
> >
> > From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
> >From: Baoquan He <b...@redhat.com>
> >Date: Wed, 24 Aug 2016 11:14:34 +0800
> >Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
> >  and maxcpus
> >
> > From the old description people still can't get what's the exact
> >difference between nr_cpus and maxcpus. Especially in kdump kernel
> >nr_cpus is always suggested if it's implemented in the ARCH. The
> >reason is nr_cpus is used to limit the max number of possible cpu
> >in system, the sum of already plugged cpus and hot plug cpus can't
> >exceed its value. However maxcpus is used to limit how many cpus
> >are 

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/25/16 at 01:10pm, Jonathan Corbet wrote:
> On Wed, 24 Aug 2016 13:06:45 +0800
> Baoquan He <b...@redhat.com> wrote:
> 
> > Hi Jon, do you think change as below is OK to you?
> 
> So nr_cpus is the maximum value, and maxcpus is the current number.
> Figures.  No wonder the documentation is confusing...

Yes. Thanks for reviewing this patchset.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >On Fri, 19 Aug 2016 08:33:21 +0800
> >"Zhou, Wenjian/周文剑" <zhouwj-f...@cn.fujitsu.com> wrote:
> >
> >>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>I think it is a good choice to describe it in kernel-parameters.txt.
> >>
> >>Then, only two things need to be done I think.
> >>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>
> >>How do you think?
> >
> >That is not quite what I had in mind, sorry.  What I would really like to
> >see in kernel-parameters.txt is an explanation of how those two parameters
> >differ - what do they do differently and how should a user choose one over
> >the other?  What we have now offers no guidance in that matter.
> >
> 
> I thought about it. I think user may not need this.
> What user really want to know is how to choose.
> And it is also not a hard work. If nr_cpus is not supported by the ARCH, use 
> maxcpus.
> Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be 
> supported
> by some ARCHes.

I think Jon is suggesting that a note can be added into
kernel-parameter.txt to tell what's the difference between nr_cpus and
max_cpus. I checked code and discussed within our kdump team, max_cpus
is used to limit how many 'present' cpus are allowed to be brought up
during system bootup, while nr_cpus is used to set the upper limit of
'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
plug, means during bootup you want to bring up 4 present cpus, but
later you could physically hot plug 4 others. Because of attribute of
some static percpu variables, we need pre-allocate memory for all
possible cpus though some of them may not be really used if no extra
cpu physically hot plugged after system bootup.

Hence for kdump kernel, people never want to do a cpu hot plug in there.
That's why we want to use nr_cpus to limit the number of possible cpu to
save memory. E.g still on my laptop, if I want to do a kdump, the number
of possible cpu is still 8, but you may want to use only 1 cpu to dump,
maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
is much better. While with specifying max_cpus=1, the number of possible
cpu is still 8. That's the reason. On x86_64 and s390, there's another
kernel para "possible_cpus=xx" which can be used to set possible cpus for
cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
I am not very sure why this is introduced, number of possible cpu is
decided by the min value of nr_cpus= and possible_cpus=.

nr_cpus and maxcpus might not be very clear to people which are
described in Documentation/kernel-parameters.txt.

Hi Jon, do you think change as below is OK to you?


>From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
From: Baoquan He <b...@redhat.com>
Date: Wed, 24 Aug 2016 11:14:34 +0800
Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
 and maxcpus

>From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in the ARCH. The
reason is nr_cpus is used to limit the max number of possible cpu
in system, the sum of already plugged cpus and hot plug cpus can't
exceed its value. However maxcpus is used to limit how many cpus
are allowed to be brought up during bootup.

Signed-off-by: Baoquan He <b...@redhat.com>
---
 Documentation/kernel-parameters.txt | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 46c030a..25d3b36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
than or equal to this physical address is ignored.
 
maxcpus=[SMP] Maximum number of processors that an SMP kernel
-   should make use of.  maxcpus=n : n >= 0 limits the
-   kernel to using 'n' processors.  n=0 is a special case,
-   it is equivalent to "nosmp", which also disables
-   the IO APIC.
+   will bring up during bootup.  maxcpus=n : n >= 0 limits
+   the kernel to b

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Baoquan He]

On 04/28/16 at 10:28am, Russell King wrote:
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const 
> Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr 
> *sechdrs,
>   unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> + return page_to_pfn(page);
> +}
> +#endif

I am thinking if it's appropriate to introduce a new concept which only
exists in a certain system of a certain ARCH. Is it unavoidable? If have
to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
might not need to know about boot view physical address and kernel view
physical address things when they just want to understand kexec
implementation related to one ARCH except of ARM, even related to ARM
but not Keystone 2.

> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> + return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> + return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> + return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> + return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> + return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, 
> unsigned long entry,
>  
>   if (kexec_on_panic) {
>   /* Verify we have a valid entry point */
> - if ((entry < crashk_res.start) || (entry > crashk_res.end))
> + if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> + (entry > phys_to_boot_phys(crashk_res.end)))
>   return -EADDRNOTAVAIL;
>   }
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>   mstart = image->segment[i].mem;
>   mend = mstart + image->segment[i].memsz - 1;
>   /* Ensure we are within the crash kernel limits */
> - if ((mstart < crashk_res.start) ||
> - (mend > crashk_res.end))
> + if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> + (mend > phys_to_boot_phys(crashk_res.end)))
>   return result;
>   }
>   }
> @@ -354,7 +354,7 @@ static struct page 
> *kimage_alloc_normal_control_pages(struct kimage *image,
>   pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>   if (!pages)
>   break;
> - pfn   = page_to_pfn(pages);
> + pfn   = page_to_boot_pfn(pages);
>   epfn  = pfn + count;
>   addr  = pfn << PAGE_SHIFT;
>   eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, 
> kimage_entry_t entry)
>   return -ENOMEM;
>  
>   ind_page = page_address(page);
> - *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> + *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>   image->entry = ind_page;
>   image->last_entry = ind_page +
> ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>   for (ptr = >head; (entry = *ptr) && !(entry & IND_DONE); \
>   ptr = (entry & IND_INDIRECTION) ? \
> - phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> + boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>   struct page *page;
>  
> - page = pfn_to_page(entry >> PAGE_SHIFT);
> + page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>   kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage 
> *image,
>* have a match.
>*/
>   list_for_each_entry(page, >dest_pages, lru) {
> - addr = 

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:12am, Russell King - ARM Linux wrote:
> On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> > Could you please help tell why arm PAE kernel can be put above 4G?
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> This is explained in the covering email to the series.
> 
> The explanation given by Pratyush was incomplete.

Yeah, he said non LPAE also has PHYS_OFFSET later to me. In fact this
patch is totally unharmful to other ARCHes, I just can't stand the
curiosity. Sorry about this.

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

[Baoquan He]

On 05/02/16 at 02:58pm, Dave Hansen wrote:
> On 05/02/2016 02:41 PM, Thomas Garnier wrote:
> > Minor change that allows early boot physical mapping of PUD level virtual
> > addresses. This change prepares usage of different virtual addresses for
> > KASLR memory randomization. It has no impact on default usage.
> ...
> > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> > index 89d9747..6adfbce 100644
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -526,10 +526,10 @@ phys_pud_init(pud_t *pud_page, unsigned long addr, 
> > unsigned long end,
> >  {
> > unsigned long pages = 0, next;
> > unsigned long last_map_addr = end;
> > -   int i = pud_index(addr);
> > +   int i = pud_index((unsigned long)__va(addr));
> >  
> > for (; i < PTRS_PER_PUD; i++, addr = next) {
> > -   pud_t *pud = pud_page + pud_index(addr);
> > +   pud_t *pud = pud_page + pud_index((unsigned long)__va(addr));
> > pmd_t *pmd;
> > pgprot_t prot = PAGE_KERNEL;
> 
> pud_index() is supposed to take a virtual address.  We were passing a
> physical address in here, and it all just worked because PAGE_OFFSET is
> PUD-aligned.  Now that you are moving PAGE_OFFSET around a bit and not
> PUD-aligning it, this breaks.  Right?

Yes. Acutally here code is tricky since PAGE_OFFSET is PUD-aligned or
. Usually we setup memory mapping with physical addr and the
corresponding virtual addr, here for less parameter we only pass in
physical addr. X86 people need to make it clear about this. Of course
explaining it in patch log is also helpful.

I have a tiny concern about phys_pmd_init(), both phys_pud_init and
phys_pte_init name 2nd parameter as 'addr', phys_pmd_init use 'address'.
If this can be changed to make them look consistent completist would
have a good sleep from now on.

Thanks
Baoquan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:23am, Pratyush Anand wrote:
> Hi Baoquan,
> 
> On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> > Hi Pratyush,
> > 
> > Could you please help tell why arm PAE kernel can be put above 4G?
> 
> PAE system can have physical addresses above 4G. So, if a CPU is supporting 
> the
> LPAE page table format then we should be able to access physical addresses
> beyond 4G.

OK, after patient explanation from Pratush on irc, I finally understand on
arm LPAE there's PHYS_OFFSET which indicats the physical address of main
memory since arm could map some amount of device memory to cpu address space
below 4G. Then physical ram has to be started from above 4G form cpu
point of view. That's why kernel need be put above 4G. It's fair enough to
fix it in this patch. Certainly if this explanation is also added into
patch log, non arm developer will understand the change better.

Thanks
Baoquan

> 
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
> seems most appropriate. So, kernel variable may land into above 4G locations,
> even with the platform in other architecture (with PAE support), if start of 
> RAM
> is located very high,
> 
> So, in my opinion it would be safer to have these changes for other ARCHs as
> well.
> 
> ~Pratyush
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

This patch is clearly related to kdump. The prefix of subject should be
changed to kdump. Kexec doesn't need to handle vmcore things. 

And patches realted to kexec/kdump should be CCed to Andrew, he usually
picks up and add them into akpm tree.

Hi Pratyush,

Could you please help tell why arm PAE kernel can be put above 4G?
Since the change is related to common code, I am curious about how
it's so different with other ARCHs.

Thanks
Baoquan


On 04/29/16 at 09:17pm, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland  wrote:
> > On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> >> > +   phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> >> > +   return sprintf(buf, "%pa %x\n", _base,
> >>
> >> Why do we pass _base? Shouldn't it be vmcore_base?
> >
> > The %pa* printk format specifiers take the value by reference (as
> > phys_addr_t and friends are not necessarily the same width as a
> > pointer). Per Documentation/printk-formats.txt:
> >
> > Physical addresses types phys_addr_t:
> >
> > %pa[p]  0x01234567 or 0x0123456789abcdef
> >
> > For printing a phys_addr_t type (and its derivatives, such as
> > resource_size_t) which can vary based on build options, regardless 
> > of
> > the width of the CPU data path. Passed by reference.
> >
> > So the above prints the value of vmcore_base as expected.
> 
> Thanks a lot Mark for explaining :-)
> 
> Reviewed-by: Pratyush Anand 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html