On Fri, Oct 19, 2007 at 09:55:29PM +0200, Petr Tesarik wrote:
> Hi,
>
> with Shaohua Li's patch we can get rid of much of the ugly code in
> arch/ia64/kernel/ptrace.c:
>
> - find_thread_for_addr() is no longer needed
> - most calls to ia64_poke() and ia64_peek() can be converted to
>simple
Hi,
with Shaohua Li's patch we can get rid of much of the ugly code in
arch/ia64/kernel/ptrace.c:
- find_thread_for_addr() is no longer needed
- most calls to ia64_poke() and ia64_peek() can be converted to
simple accesses to the VM
This patch is incremental with Shaohua Li's fix, so it can
On Thu, 2007-10-18 at 12:59 +0200, Petr Tesarik wrote:
> Shaohua Li wrote:
> > On Wed, 2007-10-17 at 16:56 +0200, Petr Tesarik wrote:
> >> Shaohua Li wrote:
> >>> On Fri, 2007-09-07 at 09:11 -0600, David Mosberger-Tang wrote:
> Anything that avoids complicating the kernel exit path is worth do
* Luck, Tony <[EMAIL PROTECTED]>:
> > The only real change from the prior version is that I change the
> > intialization of socket_id to 0 as default. I think the benefit
> > of displaying information from PAL/SAL (when available) on older
> > platforms outweighs the oddity that the user may see ph
> The only real change from the prior version is that I change the
> intialization of socket_id to 0 as default. I think the benefit
> of displaying information from PAL/SAL (when available) on older
> platforms outweighs the oddity that the user may see physical_id
> = 0 for multiple CPUs occasion
Avoid the use of cmpxchg in __clear_bit_unlock by calling __clear_bit.
__clear_bit uses a volatile pointer and will generate a store with
release semantics as shown by Zoltan. Add a barrier to make sure that
the compiler does not reorder instructions around it.
Signed-off-by: Christoph Lameter <[E
On Fri, 19 Oct 2007, Zoltan Menyhart wrote:
> Can you please tell me what is the advantage of ".nta " on the store?
> I far as I can see in the I2 Microarch. Guide, Table 3-2 Processor
> Cache Hints, ".nta " on stores means:
> - L2 NRU bit is not updated
> - No slot is allocated in L3
The advanta
Hi Tony,
After a lot of rethinking (and a little bit of rework), here is
my second shot at this patch.
The only real change from the prior version is that I change the
intialization of socket_id to 0 as default. I think the benefit
of displaying information from PAL/SAL (when available) on older
* Andrew Morton <[EMAIL PROTECTED]> [2007-10-18 23:26]:
> On Thu, 18 Oct 2007 13:15:36 +0200
> Bernhard Walle <[EMAIL PROTECTED]> wrote:
>
> > This patch adds the BSS to the resource tree just as kernel text and kernel
> > data are in the resource tree. The main reason behind this is to avoid
> >
Christoph Lameter wrote:
On Fri, 19 Oct 2007, Zoltan Menyhart wrote:
You may want to avoid assembly magics:
static __inline__ void
__clear_bit_unlock(int const nr, volatile void * const addr)
{
volatile __u32 * const m = (volatile __u32 *) addr + (nr >> 5);
*m &= ~(1 << (nr & 0x1
On Fri, 19 Oct 2007, Nick Piggin wrote:
> Of course, we can avoid the fence altogether on x86 as well, because
> it simply isn't needed for release semantics.
So we can generally switch to using wmb there?
__clear_bit_unlock: A write barrier is sufficient for release semantics
Switch the smb_
On Fri, 19 Oct 2007, Zoltan Menyhart wrote:
> You may want to avoid assembly magics:
>
> static __inline__ void
> __clear_bit_unlock(int const nr, volatile void * const addr)
> {
>volatile __u32 * const m = (volatile __u32 *) addr + (nr >> 5);
>
>*m &= ~(1 << (nr & 0x1f));
> }
>
On Thursday 18 October 2007 20:54, Roland McGrath wrote:
> Some versions of ld with --build-id support will crash when using the flag
> with a linker script that discards notes. This bites ia64's check-segrel.lds.
> The bug is easy to avoid.
It's fixed in newer ld (not released yet IIRC), but why
On Thursday 18 October 2007 23:11, Roland McGrath wrote:
> When gcc uses --build-id by default, the gate.lds.S linker script runs afoul
> of the new note section and produces a bad DSO image. This fixes it.
I wonder why we bother having --build-id.
--
vda
-
To unsubscribe from this list: send the
On Friday 19 October 2007 19:14, Zoltan Menyhart wrote:
> You may want to avoid assembly magics:
>
> static __inline__ void
> __clear_bit_unlock(int const nr, volatile void * const addr)
> {
> volatile __u32 * const m = (volatile __u32 *) addr + (nr >> 5);
>
> *m &= ~(1 << (nr & 0x1
You may want to avoid assembly magics:
static __inline__ void
__clear_bit_unlock(int const nr, volatile void * const addr)
{
volatile __u32 * const m = (volatile __u32 *) addr + (nr >> 5);
*m &= ~(1 << (nr & 0x1f));
}
GCC compiles volatile loads with ".acq" and stores with ".rel".
On Thu, 2007-10-18 at 12:59 +0200, Petr Tesarik wrote:
> Shaohua Li wrote:
> > On Wed, 2007-10-17 at 16:56 +0200, Petr Tesarik wrote:
> >> Shaohua Li wrote:
> >>> On Fri, 2007-09-07 at 09:11 -0600, David Mosberger-Tang wrote:
> Anything that avoids complicating the kernel exit path is worth do
17 matches
Mail list logo
