Tomoki wrote:
> In current Linux, percpu variable `vector_irq' is not always cleared when
> a CPU is offlined. If the cpu that has the disabled irqs in vector_irq is
> hotplugged again, __setup_vector_irq() hits invalid irq vector and may
> crash.
>
> Commit f6175f5bfb4c partially fixes this, but
Tomoki wrote:
In current Linux, percpu variable `vector_irq' is not always cleared when
a CPU is offlined. If the cpu that has the disabled irqs in vector_irq is
hotplugged again, __setup_vector_irq() hits invalid irq vector and may
crash.
Commit f6175f5bfb4c partially fixes this, but was
On Sun, Feb 24, 2008 at 01:20:05PM +0100, Andi Kleen wrote:
> On Sat, Feb 23, 2008 at 06:34:39PM -0800, Suresh Siddha wrote:
> > Only allocate the FPU area when the application actually uses FPU, i.e., in
> > the
> > first lazy FPU trap. This could save memory for non-fpu using apps.
>
> Did you
On Sun, Feb 24, 2008 at 08:22:02AM +0100, Ingo Molnar wrote:
>
> * Suresh Siddha <[EMAIL PROTECTED]> wrote:
>
> > Split the FPU save area from the task struct. This allows easy
> > migration of FPU context, and it's generally cleaner. It also allows
> > the following two optimizations:
> >
>
On Sun, Feb 24, 2008 at 08:27:30AM +0100, Roger While wrote:
>
> On Sat, Feb 23, 2008 at 06:34:38PM -0800, Suresh Siddha wrote:
> > Split the FPU save area from the task struct. This allows easy migration
> > of FPU context, and it's generally cleaner. It also allows the following
> > two
On Sun, Feb 24, 2008 at 08:27:30AM +0100, Roger While wrote:
On Sat, Feb 23, 2008 at 06:34:38PM -0800, Suresh Siddha wrote:
Split the FPU save area from the task struct. This allows easy migration
of FPU context, and it's generally cleaner. It also allows the following
two optimizations:
On Sun, Feb 24, 2008 at 08:22:02AM +0100, Ingo Molnar wrote:
* Suresh Siddha [EMAIL PROTECTED] wrote:
Split the FPU save area from the task struct. This allows easy
migration of FPU context, and it's generally cleaner. It also allows
the following two optimizations:
1) only
On Sun, Feb 24, 2008 at 01:20:05PM +0100, Andi Kleen wrote:
On Sat, Feb 23, 2008 at 06:34:39PM -0800, Suresh Siddha wrote:
Only allocate the FPU area when the application actually uses FPU, i.e., in
the
first lazy FPU trap. This could save memory for non-fpu using apps.
Did you measure
On Mon, Feb 18, 2008 at 11:18:48AM -0800, Roland Dreier wrote:
> > > AFAIK mapping PCI memory WB is not allowed, so WC is really our only
> > > choice.
>
> > afaik that depends on the BAR being prefetchable or not.
>
> In my case the BAR is prefetchable.
Even if the BAR is prefetchable, on
On Mon, Feb 18, 2008 at 11:18:48AM -0800, Roland Dreier wrote:
AFAIK mapping PCI memory WB is not allowed, so WC is really our only
choice.
afaik that depends on the BAR being prefetchable or not.
In my case the BAR is prefetchable.
Even if the BAR is prefetchable, on some
On Thu, Feb 14, 2008 at 12:06:37PM -0700, Bjorn Helgaas wrote:
>
> Are you adding x2apic support for both x86 and ia64, or only for x86?
x2apic extension is specific to x86. ia64 already has an advanced lsapic,
isn't it..
thanks,
suresh
--
To unsubscribe from this list: send the line
On Thu, Feb 14, 2008 at 12:06:37PM -0700, Bjorn Helgaas wrote:
Are you adding x2apic support for both x86 and ia64, or only for x86?
x2apic extension is specific to x86. ia64 already has an advanced lsapic,
isn't it..
thanks,
suresh
--
To unsubscribe from this list: send the line unsubscribe
On Mon, Feb 11, 2008 at 06:58:46PM +0100, Andi Kleen wrote:
> On Monday 11 February 2008 18:36:06 Siddha, Suresh B wrote:
> > On Mon, Feb 11, 2008 at 04:27:23PM +0100, Andi Kleen wrote:
> > >
> > > > > That is exactly the situation in pageattr.c. You're saying t
On Mon, Feb 11, 2008 at 04:27:23PM +0100, Andi Kleen wrote:
>
> > > That is exactly the situation in pageattr.c. You're saying the manual
> > > is wrong here?
> >
> > I'm saying that we are not following step 2 (marking the pages not present)
>
> Yes that's true. It's one of the design
On Mon, Feb 11, 2008 at 06:58:46PM +0100, Andi Kleen wrote:
On Monday 11 February 2008 18:36:06 Siddha, Suresh B wrote:
On Mon, Feb 11, 2008 at 04:27:23PM +0100, Andi Kleen wrote:
That is exactly the situation in pageattr.c. You're saying the manual
is wrong here?
I'm
On Mon, Feb 11, 2008 at 04:27:23PM +0100, Andi Kleen wrote:
That is exactly the situation in pageattr.c. You're saying the manual
is wrong here?
I'm saying that we are not following step 2 (marking the pages not present)
Yes that's true. It's one of the design problems of the
On Tue, Feb 05, 2008 at 08:05:35AM +0100, Ingo Molnar wrote:
> there are many GART drivers, and the method used depends on the GART
> driver. The following GART drivers still use ioremap in one way or
> another:
There is another issue I see in the recent pageattr changes, again in the GART
On Tue, Feb 05, 2008 at 08:05:35AM +0100, Ingo Molnar wrote:
there are many GART drivers, and the method used depends on the GART
driver. The following GART drivers still use ioremap in one way or
another:
There is another issue I see in the recent pageattr changes, again in the GART
driver
This is wrt to x86 git commit f56d005d30342a45d8af2b75e82200f09600
"x86: no CPA on iounmap"
This can use performance issue. When a GART driver unmaps a RAM page,
which was mapped as UC, this commit will still retain UC attribute
on the kernel identity mapping. This can cause
On Sun, Feb 03, 2008 at 10:52:52AM +0100, Nick Piggin wrote:
> Hi guys,
>
> Just had another way we might do this. Migrate the completions out to
> the submitting CPUs rather than migrate submission into the completing
> CPU.
Hi Nick, This was the first experiment I tried on a quad core four
On Sun, Feb 03, 2008 at 10:52:52AM +0100, Nick Piggin wrote:
Hi guys,
Just had another way we might do this. Migrate the completions out to
the submitting CPUs rather than migrate submission into the completing
CPU.
Hi Nick, This was the first experiment I tried on a quad core four
package
This is wrt to x86 git commit f56d005d30342a45d8af2b75e82200f09600
x86: no CPA on iounmap
This can use performance issue. When a GART driver unmaps a RAM page,
which was mapped as UC, this commit will still retain UC attribute
on the kernel identity mapping. This can cause mysterious
On Fri, Feb 01, 2008 at 01:17:14PM +0100, Andi Kleen wrote:
> "Jike Song" <[EMAIL PROTECTED]> writes:
>
> > On 2/1/08, Rijndael Cosque <[EMAIL PROTECTED]> wrote:
> >> Hi all,
> >>
> >> I found the x2APIC spec via
> >> http://www.intel.com/products/processor/manuals/.
> >>
> >> Looks at present
On Fri, Feb 01, 2008 at 01:17:14PM +0100, Andi Kleen wrote:
Jike Song [EMAIL PROTECTED] writes:
On 2/1/08, Rijndael Cosque [EMAIL PROTECTED] wrote:
Hi all,
I found the x2APIC spec via
http://www.intel.com/products/processor/manuals/.
Looks at present there is no x2APIC support in
On Thu, Jan 24, 2008 at 05:59:33PM -0800, Roland McGrath wrote:
> + if (pos > 0 || count < sizeof(env))
> + convert_from_fxsr(, target);
Well, is the generic regset code enforce the need for this now? Can we
disallow the usage cases where the user passes smaller target buffer
size
On Thu, Jan 24, 2008 at 05:59:33PM -0800, Roland McGrath wrote:
+ if (pos 0 || count sizeof(env))
+ convert_from_fxsr(env, target);
Well, is the generic regset code enforce the need for this now? Can we
disallow the usage cases where the user passes smaller target buffer
size
Roland, Just happen to notice this bug. Can you please ack the bug fix which
needs to goto x86 mm tree.
thanks.
---
[patch] x86, i387: use convert_to_fxsr() in fpregs_set()
This fixes the bug introduced recently during the revamp of the code.
fpregs_set() need to use convert_to_fxsr() rather
Roland, Just happen to notice this bug. Can you please ack the bug fix which
needs to goto x86 mm tree.
thanks.
---
[patch] x86, i387: use convert_to_fxsr() in fpregs_set()
This fixes the bug introduced recently during the revamp of the code.
fpregs_set() need to use convert_to_fxsr() rather
On Thu, Jan 17, 2008 at 03:04:03PM -0800, Balbir Singh wrote:
> I think I found the root cause of the problem and a fix for it.
> The fix works for me.
>
Thanks Balbir. But the appended fix is more clean and appropriate. Can you
please check if it works.
---
>From Balbir Singh:
> With the
On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
> but in general we must be robust enough in this case and just degrade
> any overlapping page to UC (and emit a warning perhaps) - instead of
> failing the ioremap and thus failing the driver (and the bootup).
But then, this will
On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
but in general we must be robust enough in this case and just degrade
any overlapping page to UC (and emit a warning perhaps) - instead of
failing the ioremap and thus failing the driver (and the bootup).
But then, this will cause
On Thu, Jan 17, 2008 at 03:04:03PM -0800, Balbir Singh wrote:
I think I found the root cause of the problem and a fix for it.
The fix works for me.
Thanks Balbir. But the appended fix is more clean and appropriate. Can you
please check if it works.
---
From Balbir Singh:
With the
On Tue, Jan 15, 2008 at 11:17:58PM +0100, Ingo Molnar wrote:
>
> * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > Time to resurrect Jesse's old patches
> > i386-trim-memory-not-covered-by-wb-mtrrs.patch(which was in -mm
> > sometime back)
>
> just to
On Tue, Jan 15, 2008 at 11:17:58PM +0100, Ingo Molnar wrote:
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
Time to resurrect Jesse's old patches
i386-trim-memory-not-covered-by-wb-mtrrs.patch(which was in -mm
sometime back)
just to make sure i understood the attribute priorities right
On Mon, Jan 14, 2008 at 05:43:24PM +0100, Ingo Molnar wrote:
>
> * Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote:
>
> > Also, relying on MTRR, is like giving more importance to BIOS writer
> > than required :-). I think the best way to deal with MTRR is just to
> > not touch it. Leave it as
On Mon, Jan 14, 2008 at 05:43:24PM +0100, Ingo Molnar wrote:
* Pallipadi, Venkatesh [EMAIL PROTECTED] wrote:
Also, relying on MTRR, is like giving more importance to BIOS writer
than required :-). I think the best way to deal with MTRR is just to
not touch it. Leave it as it is and do
On Tue, Jan 08, 2008 at 11:08:15PM +0530, Vaidyanathan Srinivasan wrote:
> Hi,
>
> The following experiments were conducted on a two socket dual core
> intel processor based machine in order to understand the impact of
> sched_mc_power_savings scheduler heuristics.
Thanks for these experiments.
On Tue, Jan 08, 2008 at 11:08:15PM +0530, Vaidyanathan Srinivasan wrote:
Hi,
The following experiments were conducted on a two socket dual core
intel processor based machine in order to understand the impact of
sched_mc_power_savings scheduler heuristics.
Thanks for these experiments.
On Fri, Dec 14, 2007 at 01:10:39PM -0800, Siddha, Suresh B wrote:
> On Thu, Dec 13, 2007 at 09:23:26PM -0700, Eric W. Biederman wrote:
> > [EMAIL PROTECTED] (Eric W. Biederman) writes:
> > Ok. My analysis here was wrong. Currently pgprot_noncached and
> > ioremap_no
On Fri, Dec 14, 2007 at 12:28:25AM +, Dave Airlie wrote:
> Yes, the main use for GPUs is to have RAM pages mapped WC, and placed into
> a GART on the GPU side, currently for Intel IGD we are okay as the CPU can
> access the GPU GART aperture, but other chips exist where this isn't
>
On Thu, Dec 13, 2007 at 09:48:36PM -0700, Eric W. Biederman wrote:
> Roland Dreier <[EMAIL PROTECTED]> writes:
>
> > > > Also I didn't see anything like pgprot_wc() in the patchset (although
> >
> > > pgprot_writcombined.
> >
> > Oh I see it now (pgprot_writecombine() actually).
> >
> > However
On Thu, Dec 13, 2007 at 09:23:26PM -0700, Eric W. Biederman wrote:
> [EMAIL PROTECTED] (Eric W. Biederman) writes:
> Ok. My analysis here was wrong. Currently pgprot_noncached and
> ioremap_nocache are out of sync. With ioremap_nocache only specifying
> _PAGE_PCD and pgprot_noncached specifying
On Thu, Dec 13, 2007 at 08:48:45PM -0700, Eric W. Biederman wrote:
> > + pat = PAT(0,WB) | PAT(1,WT) | PAT(2,UC_MINUS) | PAT(3,WC) |
> > + PAT(4,WB) | PAT(5,WT) | PAT(6,UC_MINUS) | PAT(7,WC);
>
> I strongly object to this configuration.
>
> The caching modes of interest
On Thu, Dec 13, 2007 at 09:23:26PM -0700, Eric W. Biederman wrote:
[EMAIL PROTECTED] (Eric W. Biederman) writes:
Ok. My analysis here was wrong. Currently pgprot_noncached and
ioremap_nocache are out of sync. With ioremap_nocache only specifying
_PAGE_PCD and pgprot_noncached specifying
On Thu, Dec 13, 2007 at 08:48:45PM -0700, Eric W. Biederman wrote:
+ pat = PAT(0,WB) | PAT(1,WT) | PAT(2,UC_MINUS) | PAT(3,WC) |
+ PAT(4,WB) | PAT(5,WT) | PAT(6,UC_MINUS) | PAT(7,WC);
I strongly object to this configuration.
The caching modes of interest are:
On Thu, Dec 13, 2007 at 09:48:36PM -0700, Eric W. Biederman wrote:
Roland Dreier [EMAIL PROTECTED] writes:
Also I didn't see anything like pgprot_wc() in the patchset (although
pgprot_writcombined.
Oh I see it now (pgprot_writecombine() actually).
However the same comment as
On Fri, Dec 14, 2007 at 12:28:25AM +, Dave Airlie wrote:
Yes, the main use for GPUs is to have RAM pages mapped WC, and placed into
a GART on the GPU side, currently for Intel IGD we are okay as the CPU can
access the GPU GART aperture, but other chips exist where this isn't
possible, I
On Fri, Dec 14, 2007 at 01:10:39PM -0800, Siddha, Suresh B wrote:
On Thu, Dec 13, 2007 at 09:23:26PM -0700, Eric W. Biederman wrote:
[EMAIL PROTECTED] (Eric W. Biederman) writes:
Ok. My analysis here was wrong. Currently pgprot_noncached and
ioremap_nocache are out of sync
On Thu, Dec 13, 2007 at 11:47:29AM -0800, Christoph Lameter wrote:
> On Wed, 12 Dec 2007, Jeremy Fitzhardinge wrote:
>
> > I'm looking at unifying the various pgalloc+pgd_lists mechanisms between
> > 32-bit (PAE and non-PAE) and 64-bit, so I'm trying to understand why
> > these differences exist
On Wed, Dec 12, 2007 at 11:14:41AM -0800, Jeremy Fitzhardinge wrote:
> I'm looking at unifying the various pgalloc+pgd_lists mechanisms between
> 32-bit (PAE and non-PAE) and 64-bit, so I'm trying to understand why
> these differences exist in the first place.
>
> Change
On Wed, Dec 12, 2007 at 11:14:41AM -0800, Jeremy Fitzhardinge wrote:
I'm looking at unifying the various pgalloc+pgd_lists mechanisms between
32-bit (PAE and non-PAE) and 64-bit, so I'm trying to understand why
these differences exist in the first place.
Change
On Thu, Dec 13, 2007 at 11:47:29AM -0800, Christoph Lameter wrote:
On Wed, 12 Dec 2007, Jeremy Fitzhardinge wrote:
I'm looking at unifying the various pgalloc+pgd_lists mechanisms between
32-bit (PAE and non-PAE) and 64-bit, so I'm trying to understand why
these differences exist in the
Support for Intel's last branch recording to ptrace. This gives debuggers
access to this hardware feature and allows them to show an execution trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
Support for Intel's last branch recording to ptrace. This gives debuggers
access to this hardware feature and allows them to show an execution trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
restore sigcontext is taking a DNA exception while restoring FP context from
the user stack, during the sigreturn. Appended patch fixes it by doing clts()
if the app doesn't touch FP during the signal handler execution. This will
stop generating a DNA, during the fxrstor in the sigreturn.
This
restore sigcontext is taking a DNA exception while restoring FP context from
the user stack, during the sigreturn. Appended patch fixes it by doing clts()
if the app doesn't touch FP during the signal handler execution. This will
stop generating a DNA, during the fxrstor in the sigreturn.
This
On Mon, Oct 29, 2007 at 11:37:40AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 29 Oct 2007, Greg KH wrote:
> >
> > I'll be glad to revert it in -stable, if it's also reverted in Linus's
> > tree first :)
>
> We've had some changes since 2.6.23, and afaik, the
> "alloc_bootmem_high_node()" code
On Mon, Oct 29, 2007 at 11:37:40AM -0700, Linus Torvalds wrote:
On Mon, 29 Oct 2007, Greg KH wrote:
I'll be glad to revert it in -stable, if it's also reverted in Linus's
tree first :)
We've had some changes since 2.6.23, and afaik, the
alloc_bootmem_high_node() code is alreadt
On Tue, Oct 16, 2007 at 12:07:06PM -0700, Ken Chen wrote:
> We recently discovered a nasty performance bug in the kernel CPU load
> balancer where we were hit by 50% performance regression.
>
> When tasks are assigned to a subset of CPUs that span across
> sched_domains (either ccNUMA node or the
On Tue, Oct 16, 2007 at 12:07:06PM -0700, Ken Chen wrote:
We recently discovered a nasty performance bug in the kernel CPU load
balancer where we were hit by 50% performance regression.
When tasks are assigned to a subset of CPUs that span across
sched_domains (either ccNUMA node or the new
Appended patch fixes an oops while changing the vsyscall sysctl.
I am sure no one tested this code before integrating into mainline :(
BTW, using ioremap() in vsyscall_sysctl_change() to get the virtual
address of a kernel symbol sounds like an over kill.. I wonder if we
can define a simple
Appended patch fixes an oops while changing the vsyscall sysctl.
I am sure no one tested this code before integrating into mainline :(
BTW, using ioremap() in vsyscall_sysctl_change() to get the virtual
address of a kernel symbol sounds like an over kill.. I wonder if we
can define a simple
On Thu, Oct 04, 2007 at 12:05:35PM -0700, Christoph Lameter wrote:
> > > Was the page allocator pass through patchset
> > > separately applied as I requested?
> >
> > I don't believe so. Suresh?
>
> If it was a git pull then the pass through was included and never taken
> out.
It was a git
On Thu, Oct 04, 2007 at 12:05:35PM -0700, Christoph Lameter wrote:
Was the page allocator pass through patchset
separately applied as I requested?
I don't believe so. Suresh?
If it was a git pull then the pass through was included and never taken
out.
It was a git pull from the
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
> Hi, was wondering if anyone else has been tripped up by this... I've got
> 4GB of
> RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
> default, my system boots up with these MTRR settings:
>
> reg00:
git commit 34feb2c83beb3bdf13535a36770f7e50b47ef299 started using quicklists
for freeing page table pages and removed the usage of tlb_remove_page()
And looking at quicklist_free() and quicklist_free_page(), on a NUMA platform,
this can potentially free the page before the corresponding TLB
git commit 34feb2c83beb3bdf13535a36770f7e50b47ef299 started using quicklists
for freeing page table pages and removed the usage of tlb_remove_page()
And looking at quicklist_free() and quicklist_free_page(), on a NUMA platform,
this can potentially free the page before the corresponding TLB
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
Hi, was wondering if anyone else has been tripped up by this... I've got
4GB of
RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
default, my system boots up with these MTRR settings:
reg00: base=0x
On Tue, Sep 18, 2007 at 11:03:59PM -0700, Tong Li wrote:
> This patch attempts to improve CFS's SMP global fairness based on the new
> virtual time design.
>
> Removed vruntime adjustment in set_task_cpu() as it skews global fairness.
>
> Modified small_imbalance logic in find_busiest_group().
On Tue, Sep 18, 2007 at 11:03:59PM -0700, Tong Li wrote:
This patch attempts to improve CFS's SMP global fairness based on the new
virtual time design.
Removed vruntime adjustment in set_task_cpu() as it skews global fairness.
Modified small_imbalance logic in find_busiest_group(). If
On Fri, Sep 14, 2007 at 12:51:34PM -0700, Christoph Lameter wrote:
> On Fri, 14 Sep 2007, Siddha, Suresh B wrote:
> > We are trying to get the latest data with 2.6.23-rc4-mm1 with and without
> > slub. Is this good enough?
>
> Good enough. If you are concerned about the page a
On Fri, Sep 14, 2007 at 12:51:34PM -0700, Christoph Lameter wrote:
On Fri, 14 Sep 2007, Siddha, Suresh B wrote:
We are trying to get the latest data with 2.6.23-rc4-mm1 with and without
slub. Is this good enough?
Good enough. If you are concerned about the page allocator pass through
On Fri, Sep 14, 2007 at 02:00:02PM -0700, Jeremy Fitzhardinge wrote:
> Keshavamurthy, Anil S wrote:
> > Subject: [patch] Fix BIOS-e820 end address
> >
> > --snip of boot message--
> > BIOS-provided physical RAM map:
> > BIOS-e820: - 000a (usable)
> > BIOS-e820:
Christoph,
On Thu, Sep 13, 2007 at 11:03:53AM -0700, Christoph Lameter wrote:
> On Wed, 12 Sep 2007, Siddha, Suresh B wrote:
>
> > Christoph, Not sure if you are referring to me or not here. But our
> > tests(atleast on with the database workloads) approx 1.5 months or
Christoph,
On Thu, Sep 13, 2007 at 11:03:53AM -0700, Christoph Lameter wrote:
On Wed, 12 Sep 2007, Siddha, Suresh B wrote:
Christoph, Not sure if you are referring to me or not here. But our
tests(atleast on with the database workloads) approx 1.5 months or so back
showed that on ia64
On Fri, Sep 14, 2007 at 02:00:02PM -0700, Jeremy Fitzhardinge wrote:
Keshavamurthy, Anil S wrote:
Subject: [patch] Fix BIOS-e820 end address
--snip of boot message--
BIOS-provided physical RAM map:
BIOS-e820: - 000a (usable)
BIOS-e820: 000f -
On Tue, Sep 11, 2007 at 01:19:30PM -0700, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
>
> > The impression I got at vm meeting was that SLUB was good to go :(
>
> Its not? I have had Intel test this thoroughly and they assured me that it
> is up to SLAB.
Christoph, Not
On Tue, Sep 11, 2007 at 01:19:30PM -0700, Christoph Lameter wrote:
On Tue, 11 Sep 2007, Nick Piggin wrote:
The impression I got at vm meeting was that SLUB was good to go :(
Its not? I have had Intel test this thoroughly and they assured me that it
is up to SLAB.
Christoph, Not sure if
On Tue, Sep 04, 2007 at 07:35:21PM -0400, Chuck Ebbert wrote:
> On 08/28/2007 06:27 PM, Siddha, Suresh B wrote:
> > Try to fix MC/HT scheduler optimization breakage again, with out breaking
> > the FUZZ logic.
> >
> > First fix the check
> > if (*
On Tue, Sep 04, 2007 at 07:35:21PM -0400, Chuck Ebbert wrote:
On 08/28/2007 06:27 PM, Siddha, Suresh B wrote:
Try to fix MC/HT scheduler optimization breakage again, with out breaking
the FUZZ logic.
First fix the check
if (*imbalance + SCHED_LOAD_SCALE_FUZZ busiest_load_per_task
Andi/Andrew,
Can you pick this up for your trees and if there are no issues, can you please
push it to mainline before .23 gets released.
We have seen a boot failure with fewer cpu sockets populated on a MP platform.
Similar problem can happen on a fully populated system, if # of cpus <= 8
and
On Mon, Aug 27, 2007 at 12:31:03PM -0700, Siddha, Suresh B wrote:
> Essentially I observed that nice 0 tasks still endup on two cores of same
> package, with out getting spread out to two different packages. This behavior
> is same with out this fix and this fix doesn't help in any w
On Mon, Aug 27, 2007 at 12:31:03PM -0700, Siddha, Suresh B wrote:
Essentially I observed that nice 0 tasks still endup on two cores of same
package, with out getting spread out to two different packages. This behavior
is same with out this fix and this fix doesn't help in any way.
Ingo
Andi/Andrew,
Can you pick this up for your trees and if there are no issues, can you please
push it to mainline before .23 gets released.
We have seen a boot failure with fewer cpu sockets populated on a MP platform.
Similar problem can happen on a fully populated system, if # of cpus = 8
and
On Mon, Aug 27, 2007 at 09:23:24PM +0200, Ingo Molnar wrote:
>
> * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
>
> > > - if (*imbalance + SCHED_LOAD_SCALE_FUZZ < busiest_load_per_task/2) {
> > > + if (*imbalance + SCHED_LOAD_SCALE_FUZZ < busiest_load_p
en SMT/MC optimizations
> From: "Siddha, Suresh B" <[EMAIL PROTECTED]>
>
> On a four package system with HT - HT load balancing optimizations were
> broken. For example, if two tasks end up running on two logical threads
> of one of the packages, schedul
On Thu, Aug 23, 2007 at 02:13:41PM +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] So how about the patch below instead?
the right patch attached.
Subject: sched: fix broken SMT/MC optimizations
From: Siddha, Suresh B [EMAIL
On Mon, Aug 27, 2007 at 09:23:24PM +0200, Ingo Molnar wrote:
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
- if (*imbalance + SCHED_LOAD_SCALE_FUZZ busiest_load_per_task/2) {
+ if (*imbalance + SCHED_LOAD_SCALE_FUZZ busiest_load_per_task) {
Ingo, this is still broken
On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
> Previous Intro:
Thanks for doing this.
> In x86_64 and i386 architectures most arrays that are sized
> using NR_CPUS lay in local memory on node 0. Not only will most
> (99%?) of the systems not use all the slots in these
On Fri, Aug 24, 2007 at 03:26:55PM -0700, [EMAIL PROTECTED] wrote:
> Fix four instances where cpu_to_node is referenced
> by array instead of via the cpu_to_node macro. This
> is preparation to moving it to the per_cpu data area.
>
...
> unsigned long __init numa_free_all_bootmem(void)
> ---
On Fri, Aug 24, 2007 at 03:26:55PM -0700, [EMAIL PROTECTED] wrote:
Fix four instances where cpu_to_node is referenced
by array instead of via the cpu_to_node macro. This
is preparation to moving it to the per_cpu data area.
...
unsigned long __init numa_free_all_bootmem(void)
---
On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
Previous Intro:
Thanks for doing this.
In x86_64 and i386 architectures most arrays that are sized
using NR_CPUS lay in local memory on node 0. Not only will most
(99%?) of the systems not use all the slots in these arrays,
On Tue, Aug 14, 2007 at 05:23:00AM +0200, Nick Piggin wrote:
> On Mon, Aug 13, 2007 at 08:00:38PM -0700, Andrew Morton wrote:
> > Put it this way: if a 50% slowdown in context switch times yields a 5%
> > improvement in, say, balancing decisions then it's probably a net win.
> >
> > Guys, repeat
On Tue, Aug 14, 2007 at 05:23:00AM +0200, Nick Piggin wrote:
On Mon, Aug 13, 2007 at 08:00:38PM -0700, Andrew Morton wrote:
Put it this way: if a 50% slowdown in context switch times yields a 5%
improvement in, say, balancing decisions then it's probably a net win.
Guys, repeat after me:
Was playing with sched_smt_power_savings/sched_mc_power_savings and found
out that while the scheduler domains are reconstructed when sysfs settings
change, rebalance_domains() can get triggered with null domain on other cpus,
which is setting next_balance to jiffies + 60*HZ. Resulting in no
Ingo, let me know if there any side effects of this change. Thanks.
---
On a four package system with HT - HT load balancing optimizations
were broken. For example, if two tasks end up running on two logical
threads of one of the packages, scheduler is not able to pull one of
the tasks to a
Was playing with sched_smt_power_savings/sched_mc_power_savings and found
out that while the scheduler domains are reconstructed when sysfs settings
change, rebalance_domains() can get triggered with null domain on other cpus,
which is setting next_balance to jiffies + 60*HZ. Resulting in no
Ingo, let me know if there any side effects of this change. Thanks.
---
On a four package system with HT - HT load balancing optimizations
were broken. For example, if two tasks end up running on two logical
threads of one of the packages, scheduler is not able to pull one of
the tasks to a
On Mon, Aug 13, 2007 at 01:58:48PM -0700, Christoph Lameter wrote:
> On Mon, 13 Aug 2007, Siddha, Suresh B wrote:
>
> > Can we revert git commit 3cdc0ed0cea50ea08dd146c1bbc82b1bcc2e1b80 ?
>
> Only if you find another way to fix the bug that is addressed there.
Does the appende
On Mon, Aug 13, 2007 at 01:58:48PM -0700, Christoph Lameter wrote:
On Mon, 13 Aug 2007, Siddha, Suresh B wrote:
Can we revert git commit 3cdc0ed0cea50ea08dd146c1bbc82b1bcc2e1b80 ?
Only if you find another way to fix the bug that is addressed there.
Does the appended version fix both
1 - 100 of 386 matches
Mail list logo
