headers
Stephen Rothwell | 1 Mar 2010 01:20
Picon
Picon

linux-next: manual merge of the omap tree with the tree

Hi all,

Today's linux-next merge of the omap tree got a conflict in
arch/arm/plat-omap/Kconfig between commit
d6d502fa4be1acd01971476fc732c95a4da16d90 ("ARM: 5952/1: ARM: MM: Add
ARM_L1_CACHE_SHIFT_6 for handle inside each ARCH Kconfig") from the arm
tree and commits 56213ca4e440c0b6e56a48f5901c55c4ce3cf1ba ("omap2/3:
Multiboot compile fixes to compile in omap2 and omap3") and
a8eb7ca0cbb41c9cd379b8d2a2a5efb503aa65e9 ("omap3: Replace ARCH_OMAP34XX
with ARCH_OMAP3") from the omap tree.

I fixed it up (see below) and can carry the fix as necessary.
--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au

diff --cc arch/arm/plat-omap/Kconfig
index 2e3eec6,be9484a..0000000
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
 <at>  <at>  <at>  -19,10 -28,9 +28,10  <at>  <at>  <at>  config ARCH_OMAP

  config ARCH_OMAP3
  	bool "TI OMAP3"
+ 	depends on ARCH_OMAP2PLUS
  	select CPU_V7
- 	select COMMON_CLKDEV
 +	select ARM_L1_CACHE_SHIFT_6
+ 	select USB_ARCH_HAS_EHCI
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Davidsen | 1 Mar 2010 01:36

Re: [PATCH v1] compiler: prevent dead store elimination

Andi Kleen wrote:
>> Every byte in the [p,p+n[ range must be used. If you only use the
>> first byte, via e.g. asm("" :: "m"(*(char*)p)), then the compiler
>> _will_ skip scrubbing bytes beyond the first. This works with
>> gcc-3.2.3 up to gcc-4.4.3.
> 
> You forgot to credit Mikael who did all the hard work figuring
> this out?
> 
>>  /*
>> + * Dead store elimination (DSE) is an optimization that may remove a write to
>> + * a buffer that is not used anymore. Use ARRAY_PREVENT_DSE after a write when
>> + * the scrub is required for security reasons.
>> + */
>> +#define ARRAY_PREVENT_DSE(p, n)				\
> 
> Maybe it's just me, but the name is ugly.
> 
>> +	do {						\
>> +		struct __scrub { char c[n]; };		\
> 
> 
> Better typeof(*p)[n]
> 
>> +++ b/include/linux/compiler-intel.h
>>  <at>  <at>  -14,9 +14,11  <at>  <at> 
>>   * It uses intrinsics to do the equivalent things.
>>   */
>>  #undef barrier
>> +#undef ARRAY_PREVENT_DSE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nationwide Finance and loan company | 1 Mar 2010 01:30

Loan Agency


Nationwide Finance and loan company, is happy to inform you that we are giving out loan to individuals at 3%
interest rate. Interested applicant should send a notification.
Permalink | Reply | 0 comments |
headers
KAMEZAWA Hiroyuki | 1 Mar 2010 01:47
Favicon

Re: [PATCH 2/2] memcg: dirty pages instrumentation

On Fri, 26 Feb 2010 16:48:11 -0500
Vivek Goyal <vgoyal <at> redhat.com> wrote:

> On Thu, Feb 25, 2010 at 04:12:11PM +0100, Andrea Righi wrote:
> > On Tue, Feb 23, 2010 at 04:29:43PM -0500, Vivek Goyal wrote:
> > > On Sun, Feb 21, 2010 at 04:18:45PM +0100, Andrea Righi wrote:

> Because bdi_thres calculation will be based on per cgroup dirty and
> bdi_nr_reclaimable and bdi_nr_writeback will be system wide, we will be
> doing much more aggressive writeouts.
> 
> But we will not achieve parallel writeback paths so probably will not help IO
> controller a lot.
> 
> Kame-san, is it a problem, with current memory cgroups where writeback is
> not happening that actively, and you run into situation where there are too
> many dirty pages in a cgroup and reclaim can take long time?
> 
Hmm, not same situation to the global memory management, but we have similar.

In memcg, we just count user's page, "hard to reclaim" situation doesn't happen.
But "reclaim is slower than expected" is an usual problem.

When you try 
% dd id=/dev/zero of=./tmpfifle .....
under proper limitation of memcg, you'll find dd is very slow.
We know background writeback helps this situation. We need to kick background
write-back.

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frederic Weisbecker | 1 Mar 2010 02:08
Picon

Re: linux-next: build failure after merge of the blackfin tree

On Mon, Mar 01, 2010 at 12:03:21PM +1100, Stephen Rothwell wrote:
> Hi Mike,
> 
> After merging the blackfin tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> kernel/trace/trace_syscalls.c:402: error: redefinition of 'arch_syscall_addr'
> kernel/trace/trace_syscalls.c:397: note: previous definition of 'arch_syscall_addr' was here
> 
> Caused by commit d156d1881ea54ec609d92388601661c2679439bb ("ftrace: unify
> arch_syscall_addr() implementations") from the blackfin tree interacting

Oh, why is this patch in the blackfin tree?

> with commit e7b8e675d9c71b868b66f62f725a948047514719 ("tracing: Unify
> arch_syscall_addr() implementations") from Linus' tree.
> 
> These are slightly different versions of the same patch. but merging with the blackfin tree managed to add
a second copy of the above function.  I have applied the following patch for today.
> -- 
> Cheers,
> Stephen Rothwell                    sfr <at> canb.auug.org.au
> 
> From: Stephen Rothwell <sfr <at> canb.auug.org.au>
> Date: Mon, 1 Mar 2010 11:56:09 +1100
> Subject: [PATCH] blackfin: fix mismerge of kernel/trace/trace_syscalls.c
> 
> Signed-off-by: Stephen Rothwell <sfr <at> canb.auug.org.au>
> ---
>  kernel/trace/trace_syscalls.c |    5 -----
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yuhong Bao | 1 Mar 2010 02:31
Picon
Favicon

RE: Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks


>> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd
find these benchmarks done by Phoronix of interest:
>> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>>
>
> The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
> (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
> stock 32-bit kernel.
BTW, Linus posted this about HIGHMEM and PAE:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=78966&threadid=78766&roomid=2
A few corrections though. HIMEM.SYS was never about memory windowing, EMS was.
The way the 286 could access 16MB of memory was plain old segmentation, just in a different way than EMS did.
And the main issue with PAE in Windows was driver issues, I think, which is why when they enabled PAE to get the
NX bit, they limited physical address space to 32-bit on client versions of Windows.

Yuhong Bao
 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Yuhong Bao | 1 Mar 2010 02:38
Picon
Favicon

RE: Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks


> The way the 286 could access 16MB of memory was plain old segmentation, just in a different way than EMS did.
I mean different from the way 8086/8088 did, which was that the selector's base address was always the
selector value itself shifted by 4 bit to get a 20-bit base address. The 286 and later supported this in
their real mode (and virtual 8086 mode in 386 and later) for compatibility. But in their protected mode,
the selector was looked up in the GDT/LDT to get the base address and length of the segment as well as
protection attributes.

Yuhong Bao
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Paul Mundt | 1 Mar 2010 02:43
Gravatar

Re: [RFC] microblaze: Support FRAME_POINTER for better backtrace

On Fri, Feb 26, 2010 at 10:49:58AM -0600, Steven J. Magnani wrote:
> On Fri, 2010-02-26 at 09:06 +0100, Michal Simek wrote:
> > 2. it is just one optimization which could help but IMHO not. Your patch 
> > expects that every stack frame size has 7/8 (doesn't matter right now) 
> > items but that's not correct expectation. (Do objdump from vmlinux and 
> > look at cpu_idle, prom_add_property and others) - that's why I think 
> > that your patch won't work.
> 
> The patch expects only that frames involved in a backtrace are _at
> least_ 8 words deep and that the frame pointer is always the 8th word of
> the frame (index 7).
> 
> In my build, cpu_idle() begins like this:
> 
>  4b8:   3021ffd8        addik   r1, r1, -40
>  4bc:   fa61001c        swi     r19, r1, 28
>  4c0:   f9e10000        swi     r15, r1, 0
> 
> ...which is a frame of 40 bytes, and a frame pointer stored 7 words into
> the frame. prom_add_property() has a frame of 48 bytes and a frame
> pointer stored 7 words in. 
> 
> Now, disable_hlt() has a runt frame of only 8 bytes when compiled with
> -fno-omit-frame-pointer. But it is a leaf function and should never show
> up in a backtrace, at least in a noMMU kernel. For MMU I suppose it's
> possible for a leaf function to oops. I don't know the implications of
> that.
> 
> Although the examples you cite don't prove your point, in looking more
> closely, I see that there _are_ non-leaf functions where the frame
(Continue reading)

Permalink | Reply | 3 comments |
headers
Shaohua Li | 1 Mar 2010 02:50
Picon
Favicon

[PATCH] cfq-iosched: quantum check tweak --resend

Currently a queue can only dispatch up to 4 requests if there are other queues.
This isn't optimal, device can handle more requests, for example, AHCI can
handle 31 requests. I can understand the limit is for fairness, but we could
do a tweak: if the queue still has a lot of slice left, sounds we could
ignore the limit. Test shows this boost my workload (two thread randread of
a SSD) from 78m/s to 100m/s.
Thanks for suggestions from Corrado and Vivek for the patch.

Signed-off-by: Shaohua Li <shaohua.li <at> intel.com>
---
 block/cfq-iosched.c |   30 ++++++++++++++++++++++++++----
 1 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index f27e535..0db07d7 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
 <at>  <at>  -19,7 +19,7  <at>  <at> 
  * tunables
  */
 /* max queue in one round of service */
-static const int cfq_quantum = 4;
+static const int cfq_quantum = 8;
 static const int cfq_fifo_expire[2] = { HZ / 4, HZ / 8 };
 /* maximum backwards seek, in KiB */
 static const int cfq_back_max = 16 * 1024;
 <at>  <at>  -2197,6 +2197,19  <at>  <at>  static int cfq_forced_dispatch(struct cfq_data *cfqd)
 	return dispatched;
 }
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tim Abbott | 1 Mar 2010 03:31

Re: [PATCH 17/24] Rename .text.reset to .text..reset.

Haavard,

How does the .text.reset section get populated on the avr32 architecture?

As far as I can tell, there's no code in the kernel to put anything in the 
.text.reset section, yet the linker script places that section at the 
start of the text section.

	-Tim Abbott

On Sat, 20 Feb 2010, Denys Vlasenko wrote:

> Signed-off-by: Denys Vlasenko <vda.linux <at> googlemail.com>
> ---
>  arch/avr32/kernel/vmlinux.lds.S |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/avr32/kernel/vmlinux.lds.S b/arch/avr32/kernel/vmlinux.lds.S
> index 9cd2bd9..5d7fe57 100644
> --- a/arch/avr32/kernel/vmlinux.lds.S
> +++ b/arch/avr32/kernel/vmlinux.lds.S
>  <at>  <at>  -26,7 +26,7  <at>  <at>  SECTIONS
>  		_stext = .;
>  		__init_begin = .;
>  			_sinittext = .;
> -			*(.text.reset)
> +			*(.text..reset)
>  			INIT_TEXT
>  			/*
>  			 * .exit.text is discarded at runtime, not
(Continue reading)

Permalink | Reply | 1 comment |

Gmane