On Fri, 6 Sep 2013, Will Deacon wrote:
> Ok, I had a crack at putting something together on top of HEAD, but I still
> see some errors due to pcpu array types (even with your patch in mainline).
> I think some of your conversions to __this_cpu_read should use this_cpu_ptr
> instead, but could you
On Thu, Sep 05, 2013 at 06:52:19PM +0100, Christoph Lameter wrote:
> On Thu, 5 Sep 2013, Will Deacon wrote:
>
> > > Ok can you take it from here and modify it? I have no build and test
> > > environment set up for ARM.
> >
> > Sure. Does that include the original arm/arm64 patches from your v3 ser
On Thu, 5 Sep 2013, Will Deacon wrote:
> > Ok can you take it from here and modify it? I have no build and test
> > environment set up for ARM.
>
> Sure. Does that include the original arm/arm64 patches from your v3 series
> as well as these two fixups?
I think so. Take whatever you can and I wil
On Thu, Sep 05, 2013 at 03:24:25PM +0100, Christoph Lameter wrote:
> On Thu, 5 Sep 2013, Will Deacon wrote:
>
> > >
> > > if (el == DBG_ACTIVE_EL1 &&
> > > - local_dec_and_test(this_cpu_ptr(&kde_ref_count)))
> > > + this_cpu_dec_return(kde_ref_count))
> > > disable &= ~DBG_MDSC
On Thu, 5 Sep 2013, Will Deacon wrote:
> >
> > if (el == DBG_ACTIVE_EL1 &&
> > - local_dec_and_test(this_cpu_ptr(&kde_ref_count)))
> > + this_cpu_dec_return(kde_ref_count))
> > disable &= ~DBG_MDSCR_KDE;
>
> Almost! I think we just need an '== 0' check on the result fro
Hi again Christoph,
On Wed, Sep 04, 2013 at 09:58:31PM +0100, Christoph Lameter wrote:
> Here is a patch to be applied after the earlier one to convert the local_t
> use to this_cpu. Not sure if I got the local_dec_and_test conversion
> right.
[...]
> @@ -118,11 +117,11 @@ void disable_debug_mon
Here is a patch to be applied after the earlier one to convert the local_t
use to this_cpu. Not sure if I got the local_dec_and_test conversion
right.
Index: linux/arch/arm64/kernel/debug-monitors.c
===
--- linux.orig/arch/arm64/kern
On Wed, 4 Sep 2013, Will Deacon wrote:
> > Atomic operations use atomic_t. this_cpu operations can only use regular
> > scalars. So the set of variables that are updated by each should be
> > distinct.
>
> Right, except that your patch contained the following hunk:
>
> Index: linux/arch/arm64/kern
On Wed, Sep 04, 2013 at 07:09:04PM +0100, Christoph Lameter wrote:
> On Wed, 4 Sep 2013, Will Deacon wrote:
>
> > On ARM, yes. I'm worried that there may be an architecture where the change-
> > or-fail operation would only fail if the access from the interrupt handler
> > *also* used that change-
On Wed, 4 Sep 2013, Will Deacon wrote:
> On ARM, yes. I'm worried that there may be an architecture where the change-
> or-fail operation would only fail if the access from the interrupt handler
> *also* used that change-or-fail instruction, which isn't the case with
> this_cpu_inc.
>
> I have no
On Wed, Sep 04, 2013 at 03:54:04PM +0100, Christoph Lameter wrote:
> On Wed, 4 Sep 2013, Will Deacon wrote:
>
> > Hmm, why can't you get interrupted during atomic64_xchg? On ARM, we have the
> > following sequence:
>
> AFAICT atomic means one uninterruptible action.
I think it's more subtle than
On Wed, Sep 04, 2013 at 03:17:09PM +0100, Christoph Lameter wrote:
> On Wed, 4 Sep 2013, Will Deacon wrote:
> > God knows! You're completely right, and we simply disable interrupts which I
> > somehow misread as taking a lock. However, is it guaranteed that mixing
> > an atomic64_* access with a th
On Wed, 4 Sep 2013, Will Deacon wrote:
> > Did you apply the first patch of this series which is a bug fix?
>
> No, sorry, I didn't see that. Do you have a branch anywhere that I can play
> with?
It was merged in Linus tree yesterday.
> > I do not see any special code for ARM for this_cpu_inc_re
On Wed, 4 Sep 2013, Will Deacon wrote:
> Hmm, why can't you get interrupted during atomic64_xchg? On ARM, we have the
> following sequence:
AFAICT atomic means one uninterruptible action.
> static inline u64 atomic64_xchg(atomic64_t *ptr, u64 new)
> {
> u64 result;
> unsigned lon
Hi Christoph,
On Tue, Sep 03, 2013 at 03:39:57PM +0100, Christoph Lameter wrote:
> On Fri, 30 Aug 2013, Will Deacon wrote:
> > ...so I don't think this is quite right, and indeed, we get a bunch of
> > errors
> > from GCC:
> >
> > arch/arm/kernel/hw_breakpoint.c: In function ‘arch_install_hw_brea
On Fri, 30 Aug 2013, Will Deacon wrote:
> This is the flavour we have for ARM's hw_breakpoint code, where we have an
> array of perf_event * instead of int...
>
> > Index: linux/arch/arm/kernel/hw_breakpoint.c
> > ===
> > --- linux.or
Hi Christoph,
Sorry for the delay in looking at this, I've been on holiday for a week.
Comments inline.
On Wed, Aug 28, 2013 at 08:48:23PM +0100, Christoph Lameter wrote:
> Transformations done to __get_cpu_var()
>
>
> 1. Determine the address of the percpu instance of the current processor.
>
On Wed, 28 Aug 2013, Russell King - ARM Linux wrote:
> On Wed, Aug 28, 2013 at 07:48:23PM +, Christoph Lameter wrote:
> > 3. Retrieve the content of the current processors instance of a per cpu
> > variable.
> >
> > DEFINE_PER_CPU(int, u);
>
> Shouldn't this be 'y' ?
Right.
> > memc
On Wed, Aug 28, 2013 at 07:48:23PM +, Christoph Lameter wrote:
> 3. Retrieve the content of the current processors instance of a per cpu
> variable.
>
> DEFINE_PER_CPU(int, u);
Shouldn't this be 'y' ?
> int x = __get_cpu_var(y)
>
>Converts to
>
> int x = __this_cpu_r
__get_cpu_var() is used for multiple purposes in the kernel source. One of them
is
address calculation via the form &__get_cpu_var(x). This calculates the address
for
the instance of the percpu variable of the current processor based on an offset.
Other use cases are for storing and retrieving d
20 matches
Mail list logo
