Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space

On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> Although there have been numerous complaints about the complexity of
> parallel programming (especially over the past 5-10 years), the plain
> truth is that the incremental complexity of parallel programming over
> that of sequential programming is not as large as is commonly believed.
> Despite that you might have heard, the mind-numbing complexity of modern
> computer systems is not due so much to there being multiple CPUs, but
> rather to there being any CPUs at all.  In short, for the ultimate in
> computer-system simplicity, the optimal choice is NR_CPUS=0.
> 
> This commit therefore limits kernel builds to zero CPUs.  This change
> has the beneficial side effect of rendering all kernel bugs harmless.
> Furthermore, this commit enables additional beneficial changes, for
> example, the removal of those parts of the kernel that are not needed
> when there are zero CPUs.
> 
> Signed-off-by: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
> Reviewed-by: Thomas Gleixner <tglx <at> linutronix.de>

Looks good, thanks for doing that.

Btw, I just got confirmation from hw folk that we can actually give you
hardware support for that code with an upcoming CPU which has NR_CPUS=0
cores.

Oh, and additionally, we can disable some of those so getting into the
negative is also doable from the hw perspective, so feel free to explore
that side of the problem too.

ACK.

[PATCH] PARISC: Cache and TLB improvements

The attach change has evolved over many months.  It dramatically  
improves the
performance and stability of PA8800/PA8900 machines with large caches.

It cuts the build time for GCC by more than a factor of two.

Without the change, I would get many random HPMCs.  The GCC libgomp  
testsuite
would crash my rp3440 regularly.  With the patch, I haven't had a HPMC  
in more
than three months.  Pthread support is also improved, and as a result,  
it is now possible
to build many Debian packages that gave problems (e.g., perl, python,  
git).

The largest part of the performance increase comes from the changes to  
flush_cache_mm.
Minor increases come from loop unrolling in pacache.S.

I removed the prefetch code because I found in testing that it didn't  
help performance.
Note the previous implementation did a couple of prefetches from the  
next page...

I have kept code to clear/copy using the tmpalias region but it is my  
impression that
using the kernel mappings is slightly faster and works fine.  The  
tmpalias code can be
enabled if desired by simply defining CONFIG_PARISC_TMPALIAS in page.h.

[PATCH] PARISC: Avoid undefined shift in cnv_float.h

The attached change fixes a float conversion problem found running the
GCC testsuite with GCC configured with --with-arch=2.0.

Signed-off-by: John David Anglin <dave.anglin <at> bell.net>

diff --git a/arch/parisc/math-emu/cnv_float.h b/arch/parisc/math-emu/cnv_float.h
index 9071e09..37299c7 100644
--- a/arch/parisc/math-emu/cnv_float.h
+++ b/arch/parisc/math-emu/cnv_float.h
 <at>  <at>  -347,16 +347,15  <at>  <at> 
     Sgl_isinexact_to_fix(sgl_value,exponent)

 #define Duint_from_sgl_mantissa(sgl_value,exponent,dresultA,dresultB)	\
-  {Sall(sgl_value) <<= SGL_EXP_LENGTH;  /*  left-justify  */		\
+  {unsigned int val = Sall(sgl_value) << SGL_EXP_LENGTH;		\
     if (exponent <= 31) {						\
     	Dintp1(dresultA) = 0;						\
-    	Dintp2(dresultB) = (unsigned)Sall(sgl_value) >> (31 - exponent); \
+    	Dintp2(dresultB) = val >> (31 - exponent);			\
     }									\
     else {								\
-    	Dintp1(dresultA) = Sall(sgl_value) >> (63 - exponent);		\
-    	Dintp2(dresultB) = Sall(sgl_value) << (exponent - 31);		\
+    	Dintp1(dresultA) = val >> (63 - exponent);			\
+    	Dintp2(dresultB) = exponent <= 62 ? val << (exponent - 31) : 0;	\
     }									\
-    Sall(sgl_value) >>= SGL_EXP_LENGTH;  /* return to original */	\
   }

Re: [PATCH] PARISC: Avoid undefined shift in cnv_float.h

On Sun, 2012-04-01 at 12:57 -0400, John David Anglin wrote:
> The attached change fixes a float conversion problem found running the
> GCC testsuite with GCC configured with --with-arch=2.0.

Could you describe the actual problem? (it helps enormously when people
look at the change logs a year later and try and work out what the
actual issue is).

Thanks,

James

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PARISC: Avoid undefined shift in cnv_float.h

On 1-Apr-12, at 1:06 PM, James Bottomley wrote:

> On Sun, 2012-04-01 at 12:57 -0400, John David Anglin wrote:
>> The attached change fixes a float conversion problem found running  
>> the
>> GCC testsuite with GCC configured with --with-arch=2.0.
>
> Could you describe the actual problem? (it helps enormously when  
> people
> look at the change logs a year later and try and work out what the
> actual issue is).

The actual problem occurs for an exponent value of 63.  This is the  
maximum
exponent value that can be passed.  This causes a left shift by 32 in  
the else
hunk of the macro.  This causes undefined behavior and the wrong value  
is
returned for dresultB.  The fix is the check "exponent <= 62".  If the  
exponent
is 63, dresultB is set to 0.

The patch also optimizes the operation a bit by copying
"Sall(sgl_value) << SGL_EXP_LENGTH" to val, so that sgl_value is not  
modified.

Dave
--
John David Anglin	dave.anglin <at> bell.net

Re: [PATCH 17/19 v2] parisc/mm/fault.c: Port OOM changes to do_page_fault

Hi,

Did anyone get a chance to review this patch ?

This is v2 of this patch set now.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TLB Miss Bug?

On 25-Nov-11, at 10:18 PM, James Bottomley wrote:

> On Thu, 2011-11-24 at 08:16 -0500, John David Anglin wrote:
>> As GCC has gotten larger with time, I started seeing hangs in the
>> stage1 compilers when they are compiled
>> with no optimization.  This first was seen with gnat1.  I now see it
>> with cc1 and cc1plus.
>>
>> The hangs always occur at the same place (ldw,s instruction) in the
>> GCC casesi insn pattern:
>>
>> (gdb) disass $pc-16,$pc+16
>> Dump of assembler code from 0x45fbec4 to 0x45fbee4:
>> 0x045fbec4 <cpp_spell_token+68>:	ldw 0(ret0),ret0
>> 0x045fbec8 <cpp_spell_token+72>:	cmpib,<<,n 3,ret0,0x45fc168
>> <cpp_spell_token+744>
>> 0x045fbecc <cpp_spell_token+76>:	ldil L%45fb800,r19
>> 0x045fbed0 <cpp_spell_token+80>:	ldo 6dc(r19),r19
>> => 0x045fbed4 <cpp_spell_token+84>:	ldw,s ret0(r19),r19
>> 0x045fbed8 <cpp_spell_token+88>:	bv,n r0(r19)
>> 0x045fbedc <cpp_spell_token+92>:	# 45fbeec
>> 0x045fbee0 <cpp_spell_token+96>:	# 45fbfc8
>>
>> What is interesting about this instruction is that it usually  
>> involves
>> an I and D access to the same page.
>
>> strace shows nothing for process.  gdb can't single step from the
>> instruction.  A break at the next
>> instruction is never hit.

HONG LEONG BANK (Malaysia)

Hello,

I contacted you to assist in distributing the money left behind by my late
client,

Edward Cheah,
Tele:+60146308549
Fax:+60(0)321784290

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Boot failure with 32bit kernel

Hi all,

I compiled a kernel with a few additional features and I was unable to
boot it. It seems that if the entry point is not 0x00100000 in vmlinux,
the boot process fails right after "Total Memory: 2048 MB".
This is the only common denominator I could find.

I've been able to reproduce this with :
 - C3600 and J5600
 - kernel 3.2.12 and 3.3.1
 - gcc 4.5.3
 - ld 2.21 and 2.22
 - palo 1.17 and 1.18

I've attached the boot output of a working and 2 broken kernels. I've
also attached a non working kconfig. To have this one, I started
from a working config and then I've added XFS as I know it's a big
chunk of code and was likely to increase the resulting binary size.

With 3.2.12, I had a working kernel until I tried
CONFIG_CC_OPTIMIZE_FOR_SIZE=y. When I did this, the resulting kernel
was slightly smaller but the entry point was further than 0x00100000.

The 10 first lines of System.map from the working 3.3.1 kernel :
10100000 T _stext
10100000 A _text
10100000 T stext
10100020 t $bss_loop
10100088 t $pgt_fill_loop
10100100 t $is_pa20

[PATCH 3/6] parisc: add missing forward declarations in asm/hardware.h

Fixes this warnings:

In file included from /home/buildbot/repos/linux/arch/parisc/include/asm/processor.h:15:0,
                 from /home/buildbot/repos/linux/arch/parisc/include/asm/spinlock.h:4,
                 from /home/buildbot/repos/linux/arch/parisc/include/asm/atomic.h:20,
                 from /home/buildbot/repos/linux/include/linux/atomic.h:4,
                 from /home/buildbot/repos/linux/arch/parisc/include/asm/bitops.h:11,
                 from /home/buildbot/repos/linux/include/linux/bitops.h:22,
                 from /home/buildbot/repos/linux/include/linux/kernel.h:19,
                 from /home/buildbot/repos/linux/include/linux/sched.h:55,
                 from /home/buildbot/repos/linux/arch/parisc/kernel/asm-offsets.c:31:
/home/buildbot/repos/linux/arch/parisc/include/asm/hardware.h:106:10: warning: ‘struct
hardware_path’ declared inside parameter list [enabled by default]
/home/buildbot/repos/linux/arch/parisc/include/asm/hardware.h:106:10: warning: its scope is
only this definition or declaration, which is probably not what you want [enabled by default]
/home/buildbot/repos/linux/arch/parisc/include/asm/hardware.h:116:59: warning: ‘struct
hardware_path’ declared inside parameter list [enabled by default]
/home/buildbot/repos/linux/arch/parisc/include/asm/hardware.h:118:47: warning: ‘struct
hardware_path’ declared inside parameter list [enabled by default]
/home/buildbot/repos/linux/arch/parisc/include/asm/hardware.h:119:57: warning: ‘struct
hardware_path’ declared inside parameter list [enabled by default]

Signed-off-by: Rolf Eike Beer <eike-kernel <at> sf-tec.de>
---
 arch/parisc/include/asm/hardware.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/parisc/include/asm/hardware.h b/arch/parisc/include/asm/hardware.h
index 4e96268..036e703 100644
--- a/arch/parisc/include/asm/hardware.h