On Tue, 25 Sep 2012 07:34:52 -0500
Cliff Wickman wrote:
> From: Cliff Wickman
>
> (this was sent as an ack on 9/13, but with incorrect title and sign-off)
>
> Ack.
> But with the adjustment below. The 'end' argument was not declared long.
>
> I tested the patch on a UV.
> It has the effect
* Cliff Wickman wrote:
> From: Cliff Wickman
>
> (this was sent as an ack on 9/13, but with incorrect title and sign-off)
>
> Ack.
> But with the adjustment below. The 'end' argument was not declared long.
>
> I tested the patch on a UV.
> It has the effect of either clearing 1 or all TLBs
* Cliff Wickman c...@sgi.com wrote:
From: Cliff Wickman c...@sgi.com
(this was sent as an ack on 9/13, but with incorrect title and sign-off)
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It has the effect of either
On Tue, 25 Sep 2012 07:34:52 -0500
Cliff Wickman c...@sgi.com wrote:
From: Cliff Wickman c...@sgi.com
(this was sent as an ack on 9/13, but with incorrect title and sign-off)
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It
From: Cliff Wickman
(this was sent as an ack on 9/13, but with incorrect title and sign-off)
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It has the effect of either clearing 1 or all TLBs in a cpu.
I added some debugging to test
From: Cliff Wickman c...@sgi.com
(this was sent as an ack on 9/13, but with incorrect title and sign-off)
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It has the effect of either clearing 1 or all TLBs in a cpu.
I added some
* Cliff Wickman wrote:
> On Thu, Sep 13, 2012 at 05:53:10PM +0200, Ingo Molnar wrote:
> >
> > Ack?
> >
> > Thanks,
> >
> > Ingo
>
> Ack.
> But with the adjustment below. The 'end' argument was not declared long.
Ok, great - mind sending the updated patch properly under a new
title
On 09/14/2012 05:20 AM, Cliff Wickman wrote:
> On Thu, Sep 13, 2012 at 05:53:10PM +0200, Ingo Molnar wrote:
>>
>> Ack?
>>
>> Thanks,
>>
>> Ingo
>
> Ack.
> But with the adjustment below. The 'end' argument was not declared long.
>
> I tested the patch on a UV.
> It has the effect of either
On Thu, Sep 13, 2012 at 05:53:10PM +0200, Ingo Molnar wrote:
>
> Ack?
>
> Thanks,
>
> Ingo
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It has the effect of either clearing 1 or all TLBs in a cpu.
I added some debugging to
On Thu, Sep 13, 2012 at 05:53:10PM +0200, Ingo Molnar wrote:
Ack?
Thanks,
Ingo
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It has the effect of either clearing 1 or all TLBs in a cpu.
I added some debugging to test for
On 09/14/2012 05:20 AM, Cliff Wickman wrote:
On Thu, Sep 13, 2012 at 05:53:10PM +0200, Ingo Molnar wrote:
Ack?
Thanks,
Ingo
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It has the effect of either clearing 1 or all
* Cliff Wickman c...@sgi.com wrote:
On Thu, Sep 13, 2012 at 05:53:10PM +0200, Ingo Molnar wrote:
Ack?
Thanks,
Ingo
Ack.
But with the adjustment below. The 'end' argument was not declared long.
Ok, great - mind sending the updated patch properly under a new
title (the
On 09/07/2012 03:10 PM, Jan Beulich wrote:
On 07.09.12 at 07:37, Alex Shi wrote:
>> @@ -1113,7 +1114,10 @@ const struct cpumask *uv_flush_tlb_others(const
>> struct
>> cpumask *cpumask,
>>
>> record_send_statistics(stat, locals, hubs, remotes, bau_desc);
>>
>> -
On 09/07/2012 03:10 PM, Jan Beulich wrote:
On 07.09.12 at 07:37, Alex Shi alex@intel.com wrote:
@@ -1113,7 +1114,10 @@ const struct cpumask *uv_flush_tlb_others(const
struct
cpumask *cpumask,
record_send_statistics(stat, locals, hubs, remotes, bau_desc);
-
>>> On 07.09.12 at 07:37, Alex Shi wrote:
> @@ -1113,7 +1114,10 @@ const struct cpumask *uv_flush_tlb_others(const struct
> cpumask *cpumask,
>
> record_send_statistics(stat, locals, hubs, remotes, bau_desc);
>
> - bau_desc->payload.address = start;
> + if (!end)
So despite
On 07.09.12 at 07:37, Alex Shi alex@intel.com wrote:
@@ -1113,7 +1114,10 @@ const struct cpumask *uv_flush_tlb_others(const struct
cpumask *cpumask,
record_send_statistics(stat, locals, hubs, remotes, bau_desc);
- bau_desc-payload.address = start;
+ if (!end)
So
On 09/07/2012 07:11 AM, Andrew Morton wrote:
> On Fri, 24 Aug 2012 16:57:35 +0800
> Alex Shi wrote:
>
>> The flush tlb optimization code has logical issue on UV platform.
>> It doesn't flush the full range at all, since it simply
>> ignores its 'end' parameter (and hence also the "all"
On Fri, 24 Aug 2012 16:57:35 +0800
Alex Shi wrote:
> The flush tlb optimization code has logical issue on UV platform.
> It doesn't flush the full range at all, since it simply
> ignores its 'end' parameter (and hence also the "all" indicator)
> in uv_flush_tlb_others() function.
>
> This patch
On Fri, 24 Aug 2012 16:57:35 +0800
Alex Shi alex@intel.com wrote:
The flush tlb optimization code has logical issue on UV platform.
It doesn't flush the full range at all, since it simply
ignores its 'end' parameter (and hence also the all indicator)
in uv_flush_tlb_others() function.
On 09/07/2012 07:11 AM, Andrew Morton wrote:
On Fri, 24 Aug 2012 16:57:35 +0800
Alex Shi alex@intel.com wrote:
The flush tlb optimization code has logical issue on UV platform.
It doesn't flush the full range at all, since it simply
ignores its 'end' parameter (and hence also the all
The flush tlb optimization code has logical issue on UV platform.
It doesn't flush the full range at all, since it simply
ignores its 'end' parameter (and hence also the "all" indicator)
in uv_flush_tlb_others() function.
This patch fixed this issue, but untested due to hardware leaking.
The flush tlb optimization code has logical issue on UV platform.
It doesn't flush the full range at all, since it simply
ignores its 'end' parameter (and hence also the all indicator)
in uv_flush_tlb_others() function.
This patch fixed this issue, but untested due to hardware leaking.
22 matches
Mail list logo