> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Sunday, December 16, 2012 4:42 PM
> To: Yu, Fenghua
> Cc: H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andre
-Original Message-
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
Sent: Sunday, December 16, 2012 4:42 PM
To: Yu, Fenghua
Cc: H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
Tigran Aivazian; Andreas Herrmann; Borislav Petkov
it has to be after #PF handler set page table patch...
otherwise when ramdisk is above 1G, customer will get early PF
exception.
In old kernel, where can I put load_ucode_bsp()? Is calling load_ucode_bsp()
after relocate_initrd() earliest place?
Thanks.
-Fenghua
--
To unsubscribe from
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Sunday, December 16, 2012 6:02 PM
> To: Yu, Fenghua
> Cc: H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andre
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Sunday, December 16, 2012 9:59 AM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andreas Herr
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Sunday, December 16, 2012 9:57 AM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andreas Herrmann; Borislav Petkov; Yinghai Lu; li
-Original Message-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Sunday, December 16, 2012 9:57 AM
To: Yu, Fenghua
Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
Tigran Aivazian; Andreas Herrmann; Borislav Petkov; Yinghai Lu; linux-
kernel; x86
Subject: Re
-Original Message-
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
Sent: Sunday, December 16, 2012 9:59 AM
To: Yu, Fenghua
Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux
-Original Message-
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
Sent: Sunday, December 16, 2012 6:02 PM
To: Yu, Fenghua
Cc: H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
Tigran Aivazian; Andreas Herrmann; Borislav Petkov
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Tuesday, December 11, 2012 9:16 AM
> To: Borislav Petkov; Yinghai Lu; H. Peter Anvin; Yu, Fenghua;
> mi...@kernel.org; linux-kernel@vger.kernel.org; t...@
-Original Message-
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
Sent: Tuesday, December 11, 2012 9:16 AM
To: Borislav Petkov; Yinghai Lu; H. Peter Anvin; Yu, Fenghua;
mi...@kernel.org; linux-kernel@vger.kernel.org; t...@linutronix.de;
h
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> On Fri, Nov 30, 2012 at 4:25 PM, tip-bot for Fenghua Yu
> wrote:
> > Commit-ID: 474355fe313391de2429ae225e0fb02f67ec6c31
> > Gitweb:
> http://git.kernel.org/tip/474355fe313391de2429ae225e0fb02f67ec6c31
> >
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
On Fri, Nov 30, 2012 at 4:25 PM, tip-bot for Fenghua Yu
fenghua...@intel.com wrote:
Commit-ID: 474355fe313391de2429ae225e0fb02f67ec6c31
Gitweb:
http://git.kernel.org/tip
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Friday, November 30, 2012 11:46 AM
> To: Yu, Fenghua
> Cc: Ingo Molnar; Thomas Gleixner; Mallick, Asit K; Tigran Aivazian;
> Andreas Herrmann; Borislav Petkov; linux-kernel; x86
> Subject
-Original Message-
From: H. Peter Anvin [mailto:h...@zytor.com]
Sent: Friday, November 30, 2012 11:46 AM
To: Yu, Fenghua
Cc: Ingo Molnar; Thomas Gleixner; Mallick, Asit K; Tigran Aivazian;
Andreas Herrmann; Borislav Petkov; linux-kernel; x86
Subject: Re: [PATCH v2 01/10
> From: Srivatsa S. Bhat [mailto:srivatsa.b...@linux.vnet.ibm.com]
> Sent: Wednesday, October 17, 2012 11:43 PM
> On 10/17/2012 05:36 AM, Yu, Fenghua wrote:
> >>> +#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
> > > +case PM_RESTORE_PREPARE:
> >>> +
From: Srivatsa S. Bhat [mailto:srivatsa.b...@linux.vnet.ibm.com]
Sent: Wednesday, October 17, 2012 11:43 PM
On 10/17/2012 05:36 AM, Yu, Fenghua wrote:
+#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
+case PM_RESTORE_PREPARE:
+ /*
+ * When system resumes from hibernation
> From: Srivatsa S. Bhat [mailto:srivatsa.b...@linux.vnet.ibm.com]
> On 10/16/2012 02:20 AM, Rafael J. Wysocki wrote:
> > On Friday 12 of October 2012 09:09:42 Fenghua Yu wrote:
> >> From: Fenghua Yu
> >>
> >> Because x86 BIOS requires CPU0 to resume from sleep, suspend or
> hibernate can't
> >>
> > > On Tuesday, October 16, 2012 10:19 PM Rafael J. Wysocki wrote:
> On Tuesday 16 of October 2012 22:12:27 Yu, Fenghua wrote:
> > > On 10/16/2012 09:47 PM, Rafael J. Wysocki wrote:
> > > > On Tuesday 16 of October 2012 11:05:18 Srivatsa S. Bhat wrote:
> >
On Tuesday, October 16, 2012 10:19 PM Rafael J. Wysocki wrote:
On Tuesday 16 of October 2012 22:12:27 Yu, Fenghua wrote:
On 10/16/2012 09:47 PM, Rafael J. Wysocki wrote:
On Tuesday 16 of October 2012 11:05:18 Srivatsa S. Bhat wrote:
On 10/16/2012 02:20 AM, Rafael J. Wysocki wrote
From: Srivatsa S. Bhat [mailto:srivatsa.b...@linux.vnet.ibm.com]
On 10/16/2012 02:20 AM, Rafael J. Wysocki wrote:
On Friday 12 of October 2012 09:09:42 Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
Because x86 BIOS requires CPU0 to resume from sleep, suspend or
hibernate can't
> > +#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
> +case PM_RESTORE_PREPARE:
> > + /*
> > +* When system resumes from hibernation, online CPU0
> because
> > +* 1. it's required for resume and
> > +* 2. the CPU was online before hibernation
> > +
> On 10/16/2012 09:47 PM, Rafael J. Wysocki wrote:
> > On Tuesday 16 of October 2012 11:05:18 Srivatsa S. Bhat wrote:
> >> On 10/16/2012 02:20 AM, Rafael J. Wysocki wrote:
> >>> On Friday 12 of October 2012 09:09:42 Fenghua Yu wrote:
> From: Fenghua Yu
>
> +
> +/*
> + *
> On Fri, Oct 12, 2012 at 09:09:40AM -0700, Fenghua Yu wrote:
> > From: Fenghua Yu
> >
> > If CONFIG_BOOTPARAM_HOTPLUG_CPU is turned on, CPU0 hotplug feature is
> enabled
> > by default.
> >
> > If CONFIG_BOOTPARAM_HOTPLUG_CPU is not turned on, CPU0 hotplug
> feature is not
> > enabled by
On Fri, Oct 12, 2012 at 09:09:40AM -0700, Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
If CONFIG_BOOTPARAM_HOTPLUG_CPU is turned on, CPU0 hotplug feature is
enabled
by default.
If CONFIG_BOOTPARAM_HOTPLUG_CPU is not turned on, CPU0 hotplug
feature is not
enabled
On 10/16/2012 09:47 PM, Rafael J. Wysocki wrote:
On Tuesday 16 of October 2012 11:05:18 Srivatsa S. Bhat wrote:
On 10/16/2012 02:20 AM, Rafael J. Wysocki wrote:
On Friday 12 of October 2012 09:09:42 Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
+
+/*
+ * When bsp_check
+#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
+case PM_RESTORE_PREPARE:
+ /*
+* When system resumes from hibernation, online CPU0
because
+* 1. it's required for resume and
+* 2. the CPU was online before hibernation
+*/
+
> >> My motivation is to use multiple CPUs in order to quickly generate
> >> crash dump on the machine with huge amount of memory. I assume such
> >> machine tends to also have a lot of CPUs. So disabling one CPU would
> >> be no problem.
> >
> > Luckily you don't need to disable any CPU to
> -Original Message-
> From: HATAYAMA Daisuke [mailto:d.hatay...@jp.fujitsu.com]
> Sent: Monday, October 15, 2012 9:35 PM
> To: linux-kernel@vger.kernel.org; ke...@lists.infradead.org;
> x...@kernel.org
> Cc: mi...@elte.hu; t...@linutronix.de; h...@zytor.com; Brown, Len;
-Original Message-
From: HATAYAMA Daisuke [mailto:d.hatay...@jp.fujitsu.com]
Sent: Monday, October 15, 2012 9:35 PM
To: linux-kernel@vger.kernel.org; ke...@lists.infradead.org;
x...@kernel.org
Cc: mi...@elte.hu; t...@linutronix.de; h...@zytor.com; Brown, Len; Yu,
Fenghua; vgo
My motivation is to use multiple CPUs in order to quickly generate
crash dump on the machine with huge amount of memory. I assume such
machine tends to also have a lot of CPUs. So disabling one CPU would
be no problem.
Luckily you don't need to disable any CPU to archive your goal with
> On Tue, Oct 2, 2012 at 2:06 AM, H. Peter Anvin wrote:
> > On 10/01/2012 09:27 AM, Borislav Petkov wrote:
> >>
> >> On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> >>>
> >>> Hey,
> >>>
> >>>Any chance of this getting merge for the 3.7 cycle?
> >>
> >>
> >> It is not ready
On Tue, Oct 2, 2012 at 2:06 AM, H. Peter Anvin h...@zytor.com wrote:
On 10/01/2012 09:27 AM, Borislav Petkov wrote:
On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
Hey,
Any chance of this getting merge for the 3.7 cycle?
It is not ready yet:
> And, btw, maybe I didn't catch this earlier, but why is in all
> user-visible options the thing called "cpu0_*"? Wouldn't it be better
> to
> call it "bsp_*"?
The kernel parameter was called bsp_hotplug before. It was changed to
cpu0_hotplug in v5 to keep uniform cpu0/CPU0 names.
Thanks.
And, btw, maybe I didn't catch this earlier, but why is in all
user-visible options the thing called cpu0_*? Wouldn't it be better
to
call it bsp_*?
The kernel parameter was called bsp_hotplug before. It was changed to
cpu0_hotplug in v5 to keep uniform cpu0/CPU0 names.
Thanks.
-Fenghua
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Tuesday, August 21, 2012 1:54 PM
> To: Yu, Fenghua
> Cc: Borislav Petkov; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borisl
> -Original Message-
> From: Borislav Petkov [mailto:b...@amd64.org]
> Sent: Tuesday, August 21, 2012 1:49 PM
> To: H. Peter Anvin
> Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borisl
> -Original Message-
> From: Borislav Petkov [mailto:b...@amd64.org]
> Sent: Monday, August 20, 2012 1:20 PM
> To: H. Peter Anvin
> Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
> Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borisl
-Original Message-
From: Borislav Petkov [mailto:b...@amd64.org]
Sent: Monday, August 20, 2012 1:20 PM
To: H. Peter Anvin
Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav
Petkov; linux-kernel
-Original Message-
From: Borislav Petkov [mailto:b...@amd64.org]
Sent: Tuesday, August 21, 2012 1:49 PM
To: H. Peter Anvin
Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav
Petkov; linux-kernel
-Original Message-
From: H. Peter Anvin [mailto:h...@zytor.com]
Sent: Tuesday, August 21, 2012 1:54 PM
To: Yu, Fenghua
Cc: Borislav Petkov; Henrique de Moraes Holschuh; Ingo Molnar; Thomas
Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav
Petkov; linux-kernel
> -Original Message-
> From: Borislav Petkov [mailto:b...@amd64.org]
> Sent: Monday, August 20, 2012 8:39 AM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86
>
-Original Message-
From: Borislav Petkov [mailto:b...@amd64.org]
Sent: Monday, August 20, 2012 8:39 AM
To: Yu, Fenghua
Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86
Subject: Re: [PATCH 00/11
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Saturday, August 18, 2012 10:25 PM
> To: Yu, Fenghua
> Cc: Henrique de Moraes Holschuh; Ingo Molnar; Thomas Gleixner; Mallick,
> Asit K; Tigran Aivazian; Andreas Herrmann; Borislav Petkov; li
-Original Message-
From: H. Peter Anvin [mailto:h...@zytor.com]
Sent: Saturday, August 18, 2012 10:25 PM
To: Yu, Fenghua
Cc: Henrique de Moraes Holschuh; Ingo Molnar; Thomas Gleixner; Mallick,
Asit K; Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-
kernel; x86
Subject
> -Original Message-
> From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
> Sent: Saturday, August 18, 2012 3:45 PM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andreas Herrmann; Borislav Petkov;
> -Original Message-
> From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
> Sent: Saturday, August 18, 2012 3:13 PM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andreas Herrmann; Borislav Petkov;
-Original Message-
From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
Sent: Saturday, August 18, 2012 3:13 PM
To: Yu, Fenghua
Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86
Subject: Re
-Original Message-
From: Henrique de Moraes Holschuh [mailto:h...@hmh.eng.br]
Sent: Saturday, August 18, 2012 3:45 PM
To: Yu, Fenghua
Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86
Subject: Re
>> How's that for a one-liner? ;)
>- the return value from acpi_cpufreq_early_init() gets ignored,
> so the module will still load, but won't work.
>- Once that is fixed, the test for !acpi_perf_data[cpu] in
> acpi_cpufreq_cpu_init() can be removed.
We will modify code in those places.
-
To
How's that for a one-liner? ;)
- the return value from acpi_cpufreq_early_init() gets ignored,
so the module will still load, but won't work.
- Once that is fixed, the test for !acpi_perf_data[cpu] in
acpi_cpufreq_cpu_init() can be removed.
We will modify code in those places.
-
To
> Saw this when running strace -f on a script on 2.6.21 on ia64
Run strace -f on 2.6.22-rc3 on Tiger4/Montecito. Couldn't reproduce
this issue. Kernel was built with both defconfig and tiger_defconfig.
Thanks.
-Fenghua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Saw this when running strace -f on a script on 2.6.21 on ia64
Run strace -f on 2.6.22-rc3 on Tiger4/Montecito. Couldn't reproduce
this issue. Kernel was built with both defconfig and tiger_defconfig.
Thanks.
-Fenghua
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
>What's "shared percpu data" ? It sounds to me like a contradiction in
>terms. Isn't percpu data supposed to only be accessed by the CPU which
>owns it to prevent cache line bouncing? In which case, what's the
point
>of sharing that data with other CPUs? Surely "shared percpu data" is
>just
What's shared percpu data ? It sounds to me like a contradiction in
terms. Isn't percpu data supposed to only be accessed by the CPU which
owns it to prevent cache line bouncing? In which case, what's the
point
of sharing that data with other CPUs? Surely shared percpu data is
just the same as
>> So what we have now is space wastage on some architectures, space
savings on
>> some, but with no measurable performance benefit due to the
infrastructure
>> itself. Why not push the infrastructure when we really need it, as
against
>> pushing it now when we are not sure if it benefits?
>
>Has there been any measurable benefit yet due to tail padding?
We don't have data that tail padding actually helps. It all
depends on what data the linker lays out in the cachelines.
As of now we just want to create the infrastructure (so that
more and more people who need it, can use it).
> elements are cacheline aligned. And as such, this differentiates the
local
> only data and remotely accessed data cleanly.
>OK, but could we please have a concise description of the impact
>of these changes on kernel memory footprint? Increase or decrease?
>And by approximately how much?
elements are cacheline aligned. And as such, this differentiates the
local
only data and remotely accessed data cleanly.
OK, but could we please have a concise description of the impact
of these changes on kernel memory footprint? Increase or decrease?
And by approximately how much?
Depending
Has there been any measurable benefit yet due to tail padding?
We don't have data that tail padding actually helps. It all
depends on what data the linker lays out in the cachelines.
As of now we just want to create the infrastructure (so that
more and more people who need it, can use it).
It
So what we have now is space wastage on some architectures, space
savings on
some, but with no measurable performance benefit due to the
infrastructure
itself. Why not push the infrastructure when we really need it, as
against
pushing it now when we are not sure if it benefits?
It makes
>> -DEFINE_PER_CPU(struct tss_struct, init_tss)
>>cacheline_internodealigned_in_smp = INIT_TSS;
>> +DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss) =
INIT_TSS;
>Good work but could we call this something shorter?
>Like
>DEFINE_CPU_SHARED(...)
The PER_CPU_SHARED_ALIGNED is
-DEFINE_PER_CPU(struct tss_struct, init_tss)
cacheline_internodealigned_in_smp = INIT_TSS;
+DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss) =
INIT_TSS;
Good work but could we call this something shorter?
Like
DEFINE_CPU_SHARED(...)
The PER_CPU_SHARED_ALIGNED is corresponding
On Wed, 9 May 2007, Andrew Morton wrote:
>> erm, it's not obviosu from all this that the patches are worth
proceeding
>> with, are they?
>What was it? 0.5% performance improvement on a synthetic benchmark?
>Process wakeup I believe?
The initial patch and discussion is from:
>hm, DEFINE_PER_CPU_SHARED_CACHELINE_ALIGNED is a bit of a mouthful.
>I wonder if we can improve things here so that we use the
runtime-detected
>cacheline size rather than the compile-time size. I guess not, given
that
>the offsets into the percpu area are calculated at build-time.
>Did you
hm, DEFINE_PER_CPU_SHARED_CACHELINE_ALIGNED is a bit of a mouthful.
I wonder if we can improve things here so that we use the
runtime-detected
cacheline size rather than the compile-time size. I guess not, given
that
the offsets into the percpu area are calculated at build-time.
Did you work
On Wed, 9 May 2007, Andrew Morton wrote:
erm, it's not obviosu from all this that the patches are worth
proceeding
with, are they?
What was it? 0.5% performance improvement on a synthetic benchmark?
Process wakeup I believe?
The initial patch and discussion is from:
On Mon, May 07, 2007 at 10:30:16AM -0700, Christoph Lameter wrote:
> Call this area "cpu shared" or so?
There are some fields in percpu section which are accessed by other
cpu's but not cache line aligned, e.g. cpu_idle_state, flush_state in
x86-64. We don't want to place those fields into same
On Mon, May 07, 2007 at 10:30:16AM -0700, Christoph Lameter wrote:
Call this area cpu shared or so?
There are some fields in percpu section which are accessed by other
cpu's but not cache line aligned, e.g. cpu_idle_state, flush_state in
x86-64. We don't want to place those fields into same
201 - 269 of 269 matches
Mail list logo
