On Fri, Jun 01, 2012 at 11:33:37AM +, Wrobel Heinz-R39252 wrote:
I believe that the basic premise is that you should provide a directly
reachable copy of the save/rstore functions, even if this means that
you need several copies of the functions.
I just fixed a very similar problem with g
commit cb83b629b remove the NODE sched domain and check if the node
distance in SLIT table is farther than REMOTE_DISTANCE, if so, it will
lose the load balance chance at exec/fork/wake_affine points.
But actually, even the node distance is farther than REMOTE_DISTANCE,
Modern CPUs also has QPI li
On Wed, 2012-06-06 at 14:52 +0800, Alex Shi wrote:
> - if (sched_domains_numa_distance[level] > REMOTE_DISTANCE)
> + if (sched_domains_numa_distance[level] > RECLAIM_DISTANCE)
I actually considered this.. I just felt a little uneasy re-purposing
the RECLAIM_DISTANCE for this, but I gu
From: Ananth N Mavinakayanahalli
On RISC architectures like powerpc, instructions are fixed size.
Instruction analysis on such platforms is just a matter of (insn % 4).
Pass the vaddr at which the uprobe is to be inserted so that
arch_uprobe_analyze_insn() can flag misaligned registration request
From: Ananth N Mavinakayanahalli
This is the port of uprobes to powerpc. Usage is similar to x86.
One TODO in this port compared to x86 is the uprobe abort_xol() logic.
x86 depends on the thread_struct.trap_nr (absent in powerpc) to determine
if a signal was caused when the uprobed instruction w
On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
> +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
> *mm, loff_t vaddr)
Don't we traditionally use unsigned long to pass vaddrs?
___
Linuxppc-dev mailing lis
On Wed, 2012-06-06 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
> One TODO in this port compared to x86 is the uprobe abort_xol() logic.
> x86 depends on the thread_struct.trap_nr (absent in powerpc) to determine
> if a signal was caused when the uprobed instruction was single-stepped/
> emula
On Tue, Jun 05, 2012 at 11:07:41AM -0500, Scott Wood wrote:
> On 06/05/2012 04:08 AM, Zhao Chenhui wrote:
> > On Fri, Jun 01, 2012 at 10:40:00AM -0500, Scott Wood wrote:
> >> I know you say this is for dual-core chips only, but it would be nice if
> >> you'd write this in a way that doesn't assume
On Wed, Jun 06, 2012 at 11:27:02AM +0200, Peter Zijlstra wrote:
> On Wed, 2012-06-06 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
> > One TODO in this port compared to x86 is the uprobe abort_xol() logic.
> > x86 depends on the thread_struct.trap_nr (absent in powerpc) to determine
> > if a si
On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
> On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
> > +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
> > *mm, loff_t vaddr)
>
> Don't we traditionally use unsigned long to pass vaddrs
On Tue, Jun 05, 2012 at 11:15:52AM -0500, Scott Wood wrote:
> On 06/05/2012 06:18 AM, Zhao Chenhui wrote:
> > On Mon, Jun 04, 2012 at 11:32:47AM -0500, Scott Wood wrote:
> >> On 06/04/2012 06:04 AM, Zhao Chenhui wrote:
> >>> On Fri, Jun 01, 2012 at 04:27:27PM -0500, Scott Wood wrote:
> On 05/1
On Tue, Jun 05, 2012 at 10:58:41AM -0500, Scott Wood wrote:
> On 06/05/2012 05:59 AM, Zhao Chenhui wrote:
> > On Fri, Jun 01, 2012 at 06:30:55PM -0500, Scott Wood wrote:
> >> On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
> >>> The jog mode frequency transition process on the MPC8536 is similar to
> >
On Wed, Jun 06, 2012 at 11:40:15AM +0200, Ingo Molnar wrote:
>
> * Ananth N Mavinakayanahalli wrote:
>
> > On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
> > > On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
> > > > +int arch_uprobe_analyze_insn(struct arch_
Hello.
On 06-06-2012 10:52, Alex Shi wrote:
commit cb83b629b
Please also specify that commit's summary in parens.
remove the NODE sched domain and check if the node
distance in SLIT table is farther than REMOTE_DISTANCE, if so, it will
lose the load balance chance at exec/fork/wake_affin
On Wed, 2012-06-06 at 09:36 +0200, Steffen Rumler wrote:
>
> how should we continue here ?
> There is the kernel panic, I've described.
>
> Technically, there is an conflict between the code generated by the
> compiler and the loader in module_32.c, at least by using -Os.
> Because the prologue/e
* Ingo Molnar [2012-06-06 11:40:15]:
>
> * Ananth N Mavinakayanahalli wrote:
>
> > On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
> > > On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
> > > > +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struc
* Ananth N Mavinakayanahalli wrote:
> On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
> > On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
> > > +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct
> > > mm_struct *mm, loff_t vaddr)
> >
> > Don'
Hi,
The patch below is intended to fix the following problem.
According to the PowerPC EABI specification, the GPR r11 is assigned
the dedicated function to point to the previous stack frame.
In the powerpc-specific kernel module loader, do_plt_call()
(in arch/powerpc/kernel/module_32.c), the GP
On 06/06, Ananth N Mavinakayanahalli wrote:
>
> From: Ananth N Mavinakayanahalli
>
> On RISC architectures like powerpc, instructions are fixed size.
> Instruction analysis on such platforms is just a matter of (insn % 4).
> Pass the vaddr at which the uprobe is to be inserted so that
> arch_uprob
Hi,
On Wed, Jun 06, 2012 at 03:30:17PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-06-06 at 00:46 +, Bhushan Bharat-R65777 wrote:
>
> > > >> memblock_end_of_DRAM() returns end_address + 1, not end address.
> > > >> While some code assumes that it returns end address.
> > > >
> > > > S
From: Benjamin Herrenschmidt
Date: Wed, 06 Jun 2012 15:30:17 +1000
> On Wed, 2012-06-06 at 00:46 +, Bhushan Bharat-R65777 wrote:
>
>> > >> memblock_end_of_DRAM() returns end_address + 1, not end address.
>> > >> While some code assumes that it returns end address.
>> > >
>> > > Shouldn't we
* Oleg Nesterov [2012-06-06 17:08:48]:
> On 06/06, Ananth N Mavinakayanahalli wrote:
> >
> > From: Ananth N Mavinakayanahalli
> >
> > On RISC architectures like powerpc, instructions are fixed size.
> > Instruction analysis on such platforms is just a matter of (insn % 4).
> > Pass the vaddr at
+err1; dcbzr0,r3
There is no such instruction, you probably meant "dcbz 0,r3"?
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 2012-06-06 at 15:05 +0530, Ananth N Mavinakayanahalli wrote:
> On Wed, Jun 06, 2012 at 11:27:02AM +0200, Peter Zijlstra wrote:
> > On Wed, 2012-06-06 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
> > > One TODO in this port compared to x86 is the uprobe abort_xol() logic.
> > > x86 depe
On 06/06/2012 04:59 AM, Zhao Chenhui wrote:
> On Tue, Jun 05, 2012 at 11:15:52AM -0500, Scott Wood wrote:
>> On 06/05/2012 06:18 AM, Zhao Chenhui wrote:
>>> If user does not enable kexec or hotplug, these codes are redundant.
>>> So use CONFIG_KEXEC and CONFIG_HOTPLUG_CPU to gard them.
>>
>> My poi
On 06/06/2012 04:31 AM, Zhao Chenhui wrote:
> On Tue, Jun 05, 2012 at 11:07:41AM -0500, Scott Wood wrote:
>> On 06/05/2012 04:08 AM, Zhao Chenhui wrote:
>>> On Fri, Jun 01, 2012 at 10:40:00AM -0500, Scott Wood wrote:
I know you say this is for dual-core chips only, but it would be nice if
On 06/05/2012 11:06 PM, Li Yang wrote:
> On Wed, Jun 6, 2012 at 2:05 AM, Scott Wood wrote:
>> You ignored "what about devices other than ethernet".
>
> No, I haven't. Other devices are so at least for now.
I don't understand that last sentence. Other devices are what?
-Scott
On 06/05/2012 10:50 PM, Ben Collins wrote:
> The commit introducing pcibios_io_space_offset() was ignoring 32-bit to
> 64-bit sign extention, which is the case on ppc32 with 64-bit resource
> addresses. This only seems to have shown up while running under QEMU for
> e500mc target. It may or may be
On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > +err1; dcbzr0,r3
>
> There is no such instruction, you probably meant "dcbz 0,r3"?
This reminds me... what would happen if we changed all our
#define r0 0
#define r1 1
etc... to:
#define r0 %r0
#define r1
On Wed, 2012-06-06 at 16:15 -0500, Scott Wood wrote:
> On 06/05/2012 10:50 PM, Ben Collins wrote:
> > The commit introducing pcibios_io_space_offset() was ignoring 32-bit to
> > 64-bit sign extention, which is the case on ppc32 with 64-bit resource
> > addresses. This only seems to have shown up wh
On Jun 6, 2012, at 5:15 PM, Scott Wood wrote:
> On 06/05/2012 10:50 PM, Ben Collins wrote:
>> The commit introducing pcibios_io_space_offset() was ignoring 32-bit to
>> 64-bit sign extention, which is the case on ppc32 with 64-bit resource
>> addresses. This only seems to have shown up while runn
On Mon, Jun 4, 2012 at 7:02 PM, Anton Blanchard wrote:
>
> I blame Mikey for this. He elevated my slightly dubious testcase:
>
> # dd if=/dev/zero of=/dev/null bs=1M count=1
>
> to benchmark status. And naturally we need to be number 1 at creating
> zeros. So lets improve __clear_user some mor
On 06/06/2012 05:01 PM, Peter Zijlstra wrote:
> On Wed, 2012-06-06 at 14:52 +0800, Alex Shi wrote:
>> - if (sched_domains_numa_distance[level] > REMOTE_DISTANCE)
>> + if (sched_domains_numa_distance[level] > RECLAIM_DISTANCE)
>
> I actually considered this.. I just felt a little unea
On 06/06/2012 05:21 PM, Benjamin Herrenschmidt wrote:
> Now that means that we can end up with funky arithmetic in a couple of
> cases:
>
> - If the bus address of the IO space is larger than the virtual address
> returned by ioremap (it's a bit silly to use large IO addresses but it's
> technica
commit ca0907b "edac: Remove the legacy EDAC ABI" broke mpc85xx_edac
in the following manner:
mpc85xx_edac.c:983:35: error: too few arguments to function 'edac_mc_alloc'
this patch puts back the missing 'layers' argument.
Cc: Mauro Carvalho Chehab
Signed-off-by: Kim Phillips
---
drivers/edac/
On Wed, Jun 06, 2012 at 06:40:54PM +0200, Segher Boessenkool wrote:
> >+err1; dcbzr0,r3
>
> There is no such instruction, you probably meant "dcbz 0,r3"?
There certainly is such an instruction, though it doesn't do exactly
what a naive reader might expect. Using 0 rather than r0 or %r0
On Wed, Jun 06, 2012 at 01:26:16PM -0500, Scott Wood wrote:
> On 06/06/2012 04:31 AM, Zhao Chenhui wrote:
> > On Tue, Jun 05, 2012 at 11:07:41AM -0500, Scott Wood wrote:
> >> On 06/05/2012 04:08 AM, Zhao Chenhui wrote:
> >>> On Fri, Jun 01, 2012 at 10:40:00AM -0500, Scott Wood wrote:
> I know
On Thu, Jun 7, 2012 at 2:29 AM, Scott Wood wrote:
> On 06/05/2012 11:06 PM, Li Yang wrote:
>> On Wed, Jun 6, 2012 at 2:05 AM, Scott Wood wrote:
>>> You ignored "what about devices other than ethernet".
>>
>> No, I haven't. Other devices are so at least for now.
>
> I don't understand that last s
Benjamin Herrenschmidt wrote:
> On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > +err1;dcbzr0,r3
> >
> > There is no such instruction, you probably meant "dcbz 0,r3"?
>
> This reminds me... what would happen if we changed all our
>
> #define r0 0
> #define
On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> Benjamin Herrenschmidt wrote:
>
> > On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > > +err1; dcbzr0,r3
> > >
> > > There is no such instruction, you probably meant "dcbz 0,r3"?
> >
> > This reminds me... what wo
Michael Ellerman wrote:
> On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> > Benjamin Herrenschmidt wrote:
> >
> > > On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > > > +err1;dcbzr0,r3
> > > >
> > > > There is no such instruction, you probably meant "d
On Thu, 2012-06-07 at 16:12 +1000, Michael Neuling wrote:
> Michael Ellerman wrote:
>
> > On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> > > Benjamin Herrenschmidt wrote:
> > >
> > > > On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > > > > +err1; dcbzr0,r
On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> One problem with this is when we construct the instructions, like using
> anything from ppc-opcode.h. eg. using PPC_POPCNTB would need to go from:
> PPC_POPCNTB(r3,r3)
> to:
> PPC_POPCNTB(3,3)
> Which is less readable IMHO.
Ye
In entry_64.S version of ret_from_except_lite, you'll notice that
in the !preempt case, after we've checked MSR_PR we test for any
TIF flag in _TIF_USER_WORK_MASK to decide whether to go to do_work
or not. However, in the preempt case, we do a convoluted trick to
test SIGPENDING only if PR was set
44 matches
Mail list logo
