On 12/13/2012 07:35 PM, Borislav Petkov wrote:
> On Thu, Dec 13, 2012 at 11:07:43AM +0800, Alex Shi wrote:
now, on the other hand, if you have two threads of a process that
share a bunch of data structures, and you'd spread these over 2
sockets, you end up bouncing data between the
On Thu, Dec 13, 2012 at 11:07:43AM +0800, Alex Shi wrote:
> >> now, on the other hand, if you have two threads of a process that
> >> share a bunch of data structures, and you'd spread these over 2
> >> sockets, you end up bouncing data between the two sockets a lot,
> >> running inefficient -->
On Thu, Dec 13, 2012 at 11:07:43AM +0800, Alex Shi wrote:
now, on the other hand, if you have two threads of a process that
share a bunch of data structures, and you'd spread these over 2
sockets, you end up bouncing data between the two sockets a lot,
running inefficient -- bad for power.
On 12/13/2012 07:35 PM, Borislav Petkov wrote:
On Thu, Dec 13, 2012 at 11:07:43AM +0800, Alex Shi wrote:
now, on the other hand, if you have two threads of a process that
share a bunch of data structures, and you'd spread these over 2
sockets, you end up bouncing data between the two sockets a
>> now, on the other hand, if you have two threads of a process that
>> share a bunch of data structures, and you'd spread these over 2
>> sockets, you end up bouncing data between the two sockets a lot,
>> running inefficient --> bad for power.
>
> Yeah, that should be addressed by the NUMA
On 12/12/2012 10:21 PM, Vincent Guittot wrote:
>>> >> If Linux is to continue to work efficiently on heterogeneous
>>> >> multi-processing platforms, it needs to provide scheduling mechanisms
>>> >> that can be exploited as per the demands of the HW architecture.
>> >
>> > Linus definitely
On Tue, Dec 11, 2012 at 08:40:40AM -0800, Arjan van de Ven wrote:
> >Let me try to understand what this means: so "performance" above with
> >8 threads means that those threads are spread out across more than one
> >socket, no?
> >
> >If so, this would mean that you have a smaller amount of tasks
On 12 December 2012 14:55, Alex Shi wrote:
>
>
> well... it's not always beneficial to group or to spread out
> it depends on cache behavior mostly which is best
Let me try to understand what this means: so "performance" above with
8 threads means that those
well... it's not always beneficial to group or to spread out
it depends on cache behavior mostly which is best
>>>
>>>
>>> Let me try to understand what this means: so "performance" above with
>>> 8 threads means that those threads are spread out across more than one
>>>
On Tue, Dec 11, 2012 at 10:10 PM, Arjan van de Ven
wrote:
> On 12/11/2012 8:13 AM, Borislav Petkov wrote:
>>
>> On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
>>>
>>> On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi
On Tue, Dec 11, 2012 at 10:10 PM, Arjan van de Ven
ar...@linux.intel.com wrote:
On 12/11/2012 8:13 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi
well... it's not always beneficial to group or to spread out
it depends on cache behavior mostly which is best
Let me try to understand what this means: so performance above with
8 threads means that those threads are spread out across more than one
socket, no?
If so, this would mean
On 12 December 2012 14:55, Alex Shi lkml.a...@gmail.com wrote:
well... it's not always beneficial to group or to spread out
it depends on cache behavior mostly which is best
Let me try to understand what this means: so performance above with
8 threads means that those threads are spread
On Tue, Dec 11, 2012 at 08:40:40AM -0800, Arjan van de Ven wrote:
Let me try to understand what this means: so performance above with
8 threads means that those threads are spread out across more than one
socket, no?
If so, this would mean that you have a smaller amount of tasks on each
On 12/12/2012 10:21 PM, Vincent Guittot wrote:
If Linux is to continue to work efficiently on heterogeneous
multi-processing platforms, it needs to provide scheduling mechanisms
that can be exploited as per the demands of the HW architecture.
Linus definitely disagree such ideas. :) So,
now, on the other hand, if you have two threads of a process that
share a bunch of data structures, and you'd spread these over 2
sockets, you end up bouncing data between the two sockets a lot,
running inefficient -- bad for power.
Yeah, that should be addressed by the NUMA patches people
On 12/12/2012 12:13 AM, Borislav Petkov wrote:
> On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
>> On 12/11/2012 7:48 AM, Borislav Petkov wrote:
>>> On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
On 12/11/2012 8:13 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results
On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
> On 12/11/2012 7:48 AM, Borislav Petkov wrote:
> >On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
> >>Another testing of parallel compress with pigz on Linus' git tree.
> >>results show we get much better
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results show we get much better performance/power with powersaving and
balance policy:
testing command:
#pigz -k -c -p$x
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
> Another testing of parallel compress with pigz on Linus' git tree.
> results show we get much better performance/power with powersaving and
> balance policy:
>
> testing command:
> #pigz -k -c -p$x -r linux* &> /dev/null
>
> On a NHM
On 12/11/2012 08:51 AM, Alex Shi wrote:
> On Mon, Dec 10, 2012 at 4:22 PM, Alex Shi wrote:
>> This patchset base on tip/sched/core tree temporary, since it is more
>> steady than tip/master. and it's easy to rebase on tip/master.
>>
>> It includes 3 parts changes.
>>
>> 1, simplified fork, patch
On 12/11/2012 08:51 AM, Alex Shi wrote:
On Mon, Dec 10, 2012 at 4:22 PM, Alex Shi alex@intel.com wrote:
This patchset base on tip/sched/core tree temporary, since it is more
steady than tip/master. and it's easy to rebase on tip/master.
It includes 3 parts changes.
1, simplified fork,
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results show we get much better performance/power with powersaving and
balance policy:
testing command:
#pigz -k -c -p$x -r linux* /dev/null
On a NHM EP box
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results show we get much better performance/power with powersaving and
balance policy:
testing command:
#pigz -k -c -p$x
On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results show we get much better performance/power with
On 12/11/2012 8:13 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results
On 12/12/2012 12:13 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results
On Mon, Dec 10, 2012 at 4:22 PM, Alex Shi wrote:
> This patchset base on tip/sched/core tree temporary, since it is more
> steady than tip/master. and it's easy to rebase on tip/master.
>
> It includes 3 parts changes.
>
> 1, simplified fork, patch 1~4, that simplified the fork/exec/wake log in
>
This patchset base on tip/sched/core tree temporary, since it is more
steady than tip/master. and it's easy to rebase on tip/master.
It includes 3 parts changes.
1, simplified fork, patch 1~4, that simplified the fork/exec/wake log in
find_idlest_group and select_task_rq_fair. it can increase
This patchset base on tip/sched/core tree temporary, since it is more
steady than tip/master. and it's easy to rebase on tip/master.
It includes 3 parts changes.
1, simplified fork, patch 1~4, that simplified the fork/exec/wake log in
find_idlest_group and select_task_rq_fair. it can increase
On Mon, Dec 10, 2012 at 4:22 PM, Alex Shi alex@intel.com wrote:
This patchset base on tip/sched/core tree temporary, since it is more
steady than tip/master. and it's easy to rebase on tip/master.
It includes 3 parts changes.
1, simplified fork, patch 1~4, that simplified the
32 matches
Mail list logo
