* Mel Gorman wrote:
> > > [...] Holding PTL across task_numa_fault is bad, but not
> > > the bad we're looking for.
> >
> > No, holding the PTL across task_numa_fault() is fine,
> > because this bit got reworked in my tree rather
> > significantly, see:
> >
> > 6030a23a1c66 sched: Move the
* Mel Gorman [2012-12-07 10:23:03]:
> This is a full release of all the patches so apologies for the flood. V9 was
> just a MIPS build fix and did not justify a full release. V10 includes Ingo's
> scalability patches because even though they increase system CPU usage,
> they also helped in a num
On Tue, Dec 11, 2012 at 09:52:38AM +0100, Ingo Molnar wrote:
>
> * Mel Gorman wrote:
>
> > On Mon, Dec 10, 2012 at 03:24:05PM +, Mel Gorman wrote:
> > > For example, I think that point 5 above is the potential source of the
> > > corruption because. You're not flushing the TLBs for the PTEs
On Tue, Dec 11, 2012 at 10:18:07AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > > This is prototype only but what I was using as a reference
> > > to see could I spot a problem in yours. It has not been even
> > > boot tested but avoids remote->remote copies, contending on
> > > P
* Ingo Molnar wrote:
> > This is prototype only but what I was using as a reference
> > to see could I spot a problem in yours. It has not been even
> > boot tested but avoids remote->remote copies, contending on
> > PTL or holding it longer than necessary (should anyway)
>
> So ... because
* Mel Gorman wrote:
> On Mon, Dec 10, 2012 at 03:24:05PM +, Mel Gorman wrote:
> > For example, I think that point 5 above is the potential source of the
> > corruption because. You're not flushing the TLBs for the PTEs you are
> > updating in batch. Granted, you're relaxing rather than restr
On Mon, Dec 10, 2012 at 03:24:05PM +, Mel Gorman wrote:
> For example, I think that point 5 above is the potential source of the
> corruption because. You're not flushing the TLBs for the PTEs you are
> updating in batch. Granted, you're relaxing rather than restricting access
> so it should be
* Srikar Dronamraju wrote:
> KernelVersion: 3.7.0-rc8-tip_master+(December 7th Snapshot)
> Please do let me know if you have questions/suggestions.
Do you still have the exact sha1 by any chance?
By the date of the snapshot I'd say that this fix:
f0c77b62ba9d sched: Fix NUMA_EXCLUDE_AFFINE
Hi Mel, Ingo,
Here are the results of running autonumabenchmark on a 64 core, 8 node
machine. Has six 32GB nodes and two 64 GB nodes.
KernelVersion: 3.7.0-rc8
Testcase: Min Max Avg
numa01: 1475.37 1615.39 1555.24
On Mon, Dec 10, 2012 at 12:39:45PM +0100, Ingo Molnar wrote:
>
> * Mel Gorman wrote:
>
> > On Fri, Dec 07, 2012 at 12:01:13PM +0100, Ingo Molnar wrote:
> > >
> > > * Mel Gorman wrote:
> > >
> > > > This is a full release of all the patches so apologies for the
> > > > flood. [...]
> > >
> >
hi Srikar,
* Srikar Dronamraju wrote:
> >
> > Either way, last night I applied a patch on top of latest tip/master to
> > remove the nr_cpus_allowed check so that numacore would be enabled again
> > and tested that. In some places it has indeed much improved. In others
> > it is still regressi
* Ingo Molnar wrote:
> > reasons. As it turns out, a printk() bodge showed that
> > nr_cpus_allowed == 80 set in sched_init_smp() while
> > num_online_cpus() == 48. This effectively disabling
> > numacore. If you had responded to the bug report, this would
> > likely have been found last Wed
* Mel Gorman wrote:
> On Fri, Dec 07, 2012 at 12:01:13PM +0100, Ingo Molnar wrote:
> >
> > * Mel Gorman wrote:
> >
> > > This is a full release of all the patches so apologies for the
> > > flood. [...]
> >
> > I have yet to process all your mails, but assuming I address all
> > your revie
On Mon, Dec 10, 2012 at 10:37:10AM +0530, Srikar Dronamraju wrote:
> >
> > Either way, last night I applied a patch on top of latest tip/master to
> > remove the nr_cpus_allowed check so that numacore would be enabled again
> > and tested that. In some places it has indeed much improved. In others
On Sun, Dec 09, 2012 at 11:17:09PM +0200, Kirill A. Shutemov wrote:
> On Sun, Dec 09, 2012 at 08:36:31PM +, Mel Gorman wrote:
> > Either way, last night I applied a patch on top of latest tip/master to
> > remove the nr_cpus_allowed check so that numacore would be enabled again
> > and tested t
* Srikar Dronamraju [2012-12-10 10:37:10]:
> >
> > Either way, last night I applied a patch on top of latest tip/master to
> > remove the nr_cpus_allowed check so that numacore would be enabled again
> > and tested that. In some places it has indeed much improved. In others
> > it is still regre
>
> Either way, last night I applied a patch on top of latest tip/master to
> remove the nr_cpus_allowed check so that numacore would be enabled again
> and tested that. In some places it has indeed much improved. In others
> it is still regressing badly and in two case, it's corrupting memory --
On Sun, Dec 09, 2012 at 08:36:31PM +, Mel Gorman wrote:
> Either way, last night I applied a patch on top of latest tip/master to
> remove the nr_cpus_allowed check so that numacore would be enabled again
> and tested that. In some places it has indeed much improved. In others
> it is still reg
* Mel Gorman wrote:
> This is a full release of all the patches so apologies for the
> flood. [...]
I have yet to process all your mails, but assuming I address all
your review feedback and the latest unified tree in tip:master
shows no regression in your testing, would you be willing to
st
19 matches
Mail list logo
