2009-01-29 19:37:28

by Cliff Wickman

[permalink] [raw]
Subject: [PATCH] x86: UV cleanup



From: Cliff Wickman <[email protected]>

This patch tweaks a couple things:

- uv_flush_tlb_others()
the WARN_ON(!in_atomic()); fails if CONFIG_PREEMPT is not enabled

The #ifdef may not be the right fix. The fix is probably in the
in_atomic macro, but I'm not sure what in_atomic() should return
if CONFIG_PREEMPT is turned off. I tested making it return 1 in that
case, but that yielded tons of warnings.

The simpler fix for tlb_uv.c would be to just drop the WARN_ON.

- uv_flush_send_and_wait() should return a pointer if the broadcast
remote tlb shootdown requests fail. That causes the conventional IPI
method of shootdown to be used.

Diffed against 2.6.29-rc2
(Ingo's tree)

Signed-off-by: Cliff Wickman <[email protected]>
---
arch/x86/kernel/tlb_uv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux/arch/x86/kernel/tlb_uv.c
===================================================================
--- linux.orig/arch/x86/kernel/tlb_uv.c
+++ linux/arch/x86/kernel/tlb_uv.c
@@ -259,7 +259,7 @@ const struct cpumask *uv_flush_send_and_
* the cpu's, all of which are still in the mask.
*/
__get_cpu_var(ptcstats).ptc_i++;
- return 0;
+ return flush_mask;
}

/*
@@ -316,7 +316,9 @@ const struct cpumask *uv_flush_tlb_other
int locals = 0;
struct bau_desc *bau_desc;

+#ifdef CONFIG_PREEMPT
WARN_ON(!in_atomic());
+#endif

cpumask_andnot(flush_mask, cpumask, cpumask_of(cpu));


2009-01-29 20:35:40

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] x86: UV cleanup


* Cliff Wickman <[email protected]> wrote:

> From: Cliff Wickman <[email protected]>
>
> This patch tweaks a couple things:
>
> - uv_flush_tlb_others()
> the WARN_ON(!in_atomic()); fails if CONFIG_PREEMPT is not enabled
>
> The #ifdef may not be the right fix. The fix is probably in the
> in_atomic macro, but I'm not sure what in_atomic() should return
> if CONFIG_PREEMPT is turned off. I tested making it return 1 in that
> case, but that yielded tons of warnings.
>
> The simpler fix for tlb_uv.c would be to just drop the WARN_ON.
>
> - uv_flush_send_and_wait() should return a pointer if the broadcast
> remote tlb shootdown requests fail. That causes the conventional IPI
> method of shootdown to be used.

hm, this isnt a cleanup but a fix - i.e. needs to go into x86/urgent as a
separate patch, right?

and this:

> @@ -316,7 +316,9 @@ const struct cpumask *uv_flush_tlb_other
> int locals = 0;
> struct bau_desc *bau_desc;
>
> +#ifdef CONFIG_PREEMPT
> WARN_ON(!in_atomic());
> +#endif

is indeed somewhat ugly - and we have no proper primitive to test for
atomicity. (mainly because we dont know about atomicity on a non-preempt
kernel)

Ingo

2009-01-29 21:28:36

by Cliff Wickman

[permalink] [raw]
Subject: Re: [PATCH] x86: UV cleanup


On Thu, Jan 29, 2009 at 09:35:17PM +0100, Ingo Molnar wrote:
>
> * Cliff Wickman <[email protected]> wrote:
>
> > From: Cliff Wickman <[email protected]>
> >
> > This patch tweaks a couple things:
> >
> > - uv_flush_tlb_others()
> > the WARN_ON(!in_atomic()); fails if CONFIG_PREEMPT is not enabled
> >
> > The #ifdef may not be the right fix. The fix is probably in the
> > in_atomic macro, but I'm not sure what in_atomic() should return
> > if CONFIG_PREEMPT is turned off. I tested making it return 1 in that
> > case, but that yielded tons of warnings.
> >
> > The simpler fix for tlb_uv.c would be to just drop the WARN_ON.
> >
> > - uv_flush_send_and_wait() should return a pointer if the broadcast
> > remote tlb shootdown requests fail. That causes the conventional IPI
> > method of shootdown to be used.
>
> hm, this isnt a cleanup but a fix - i.e. needs to go into x86/urgent as a
> separate patch, right?

Yes, it is a fix. I'll re-post, and send the WARN_ON issue as a
separate patch.


> and this:
>
> > @@ -316,7 +316,9 @@ const struct cpumask *uv_flush_tlb_other
> > int locals = 0;
> > struct bau_desc *bau_desc;
> >
> > +#ifdef CONFIG_PREEMPT
> > WARN_ON(!in_atomic());
> > +#endif
>
> is indeed somewhat ugly - and we have no proper primitive to test for
> atomicity. (mainly because we dont know about atomicity on a non-preempt
> kernel)
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
Cliff Wickman
Silicon Graphics, Inc.
[email protected]
(651) 683-3824