> On Tue, 2010-02-09 at 16:24 +0100, Pavel Machek wrote:
> > ...according to gcc docs, sp should be global, or placement in
> > register is not guaranteed (except at asm boundaries, but there are
> > none).
>
> Sorry I'm not sure I grok what you mean.
Well, according to gcc doscs and my experienc
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/hw_breakpoint.h | 55
Hi Ben,
Please find the version XIII of the patch that ports the
hw-breakpoint interfaces (in kernel/hw_breakpoint.c) to PPC64. A new
patchset is necessitated due to a bug triggered by user-space breakpoint
requests.
This patch should not conflict with work done to enable debug register
us
On Mon, 2010-02-15 at 15:06 +1100, Anton Blanchard wrote:
>
> Yeah that was my primary concern. Right now these things fail 100%, so
> no one is relying on it. The worry is if people start writing their own
> crazy low level system call + locking stubs that might work most of the
> time (if we rem
Hi Ben,
> Well, the main issue here is leaking kernel reservations into userspace,
> and thus the question of whether it is a big deal or not. There's also
> an issue I can see with signals.
>
> The risk with kernel reservations leaking into userspace is a problem on
> some processors that do n
On Mon, 2010-02-15 at 12:40 +1100, Anton Blanchard wrote:
> Right now we clear the larx reservation on every system call exit. No code
> should exist that tries to make use of larx/stcx across a system call (because
> it would fail 100% of the time).
>
> We could continue to play it safe but syste
Right now we clear the larx reservation on every system call exit. No code
should exist that tries to make use of larx/stcx across a system call (because
it would fail 100% of the time).
We could continue to play it safe but system call latency affects so many
workloads. In the past we have alrea
From: Grant Likely
Date: Sat, 13 Feb 2010 09:03:09 -0700
> Both allnodes and devtree_lock are defined in common code. The
> extern declaration should be in the common header too so that the
> compiler can type check. allnodes is already in of.h, but
> devtree_lock should be declared there too.
On Sun, Feb 14, 2010 at 7:00 AM, Michal Simek
wrote:
> Grant Likely wrote:
>>
>> From: Jeremy Kerr
>>
>> We don't always have lmb available, so make arches provide an
>> early_init_dt_alloc_memory_arch() to handle the allocation of
>> memory in the fdt code.
>>
>> When we don't have lmb.h include
Grant Likely wrote:
Here's another batch of cleanup patches from my test-devicetree branch.
A number of cleanups, corrections and minor merges of common code.
Also a patch from Jeremy to make the flat tree work on architectures
without LMB (arm).
Once I've collected acks on these, I'll move them
On Sat, Feb 13, 2010 at 11:10 PM, Benjamin Herrenschmidt
wrote:
> On Sat, 2010-02-13 at 09:02 -0700, Grant Likely wrote:
>> From: Jeremy Kerr
>>
>> For platforms that have CONFIG_OF optional, we need to make the contents
>> of linux/of.h conditional on CONFIG_OF.
>>
>> Signed-off-by: Jeremy Kerr
Grant Likely wrote:
From: Jeremy Kerr
We don't always have lmb available, so make arches provide an
early_init_dt_alloc_memory_arch() to handle the allocation of
memory in the fdt code.
When we don't have lmb.h included, we need asm/page.h for __va.
Signed-off-by: Jeremy Kerr
Signed-off-by:
On Fri, 2010-02-05 at 14:57 -0600, Joel Schopp wrote:
> On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
> there is performance benefit to idling the higher numbered threads in
> the core.
>
> This patch implements arch_scale_smt_power to dynamically update smt
> thread po
13 matches
Mail list logo
