Re: kmemcheck on ARM

On Thu, 5 May 2011, Christian Robottom Reis wrote: > On Thu, May 05, 2011 at 07:28:33PM -0400, Nicolas Pitre wrote: > > On Thu, 5 May 2011, Christian Robottom Reis wrote: > > > > > Last quasi-random question of the night: would reviving the kmemcheck > > > ARM port (that IIRC was hacked up a whil

Re: kmemcheck on ARM

On Thu, May 05, 2011 at 07:28:33PM -0400, Nicolas Pitre wrote: > On Thu, 5 May 2011, Christian Robottom Reis wrote: > > > Last quasi-random question of the night: would reviving the kmemcheck > > ARM port (that IIRC was hacked up a while back) be something useful, or > > is it something that is to

Re: kmemcheck on ARM

On Thu, 5 May 2011, Christian Robottom Reis wrote: > Last quasi-random question of the night: would reviving the kmemcheck > ARM port (that IIRC was hacked up a while back) be something useful, or > is it something that is too niche to be worth it? At the board's > request, I was looking across pl

oom-killer, vm.overcommit & swap

I believe that some of these random application crashes claiming to be out-of-memory have to do with the fact that swap is off by default. Knowing that to be an issue from my experience with OpenEmbedded I preemptively set vm.overcommit_memory = 2 vm.overcommit_ratio = 100 in /etc/sysctl.conf H

Re: linaro-android track

On Thu, 5 May 2011 15:49:06 +0200, Alexander Sack wrote: > On Thu, May 5, 2011 at 2:59 AM, Michael Hudson-Doyle > wrote: > > On Wed, 4 May 2011 09:30:53 +0300, Paul Sokolovsky > > wrote: > >> On Wed, 04 May 2011 11:40:50 +1200 > >> Michael Hudson-Doyle wrote: > >> that Android team's session c

Re: Optimized kernel memcpy/memset

David Gilbert writes: >> The memcpy case is not interesting.  Not at all.  Most kernel memcpy >> calls are for small size copies.  The large copy instances are just bad >> and misdesigned in the first place if they rely on memcpy (maybe they >> should simply have a custom copy function, maybe imp

Re: How to make a defconfig that is likely to work well

Thanks for the tip. I haven't gotten a kernel panic since I used that config mix as my base. However, I have been getting strange memory errors from applications. AJ ONeal On Mon, May 2, 2011 at 9:36 PM, Andy Doan wrote: > On 05/02/2011 05:45 PM, AJ ONeal wrote: > > Is there some sort of base

kmemcheck on ARM

Last quasi-random question of the night: would reviving the kmemcheck ARM port (that IIRC was hacked up a while back) be something useful, or is it something that is too niche to be worth it? At the board's request, I was looking across platform gaps and this feature was one of the things that I fo

Re: Optimized kernel memcpy/memset

On Thu, 5 May 2011, Christian Robottom Reis wrote: > Hey there, > > I was asked today in the board meeting about the use of NEON > routines in the kernel; I said we had looked into this but hadn't done > it because a) it wasn't conclusively better and b) if better, it would > need to be done

Re: Optimized kernel memcpy/memset

On Thu, 5 May 2011, David Gilbert wrote: > Yes, while I've not actually looked at coding CRC32 or the crypto things > I agree that they feel like they have much more room for working with; > it's outside of the scope of what I was asked to look at however. Well, you said that the current memcpy c

[PATCH v3] sdio: optimized SDIO IRQ handling for single irq

From: Stefan Nilsson XK If there is only 1 function interrupt registered it is possible to improve performance by directly calling the irq handler and avoiding the overhead of reading the CCCR registers. Signed-off-by: Per Forlin Acked-by: Ulf Hansson Reviewed-by: Nicolas Pitre --- drivers/m

[PATCH v3] sdio: optimized SDIO IRQ handling for single irq

Optimize performance for single irq Changes since v2. * Clarify comment in process_sdio_pending_irqs * Simplify sdio_single_irq if-condition Stefan Nilsson XK (1): sdio: optimized SDIO IRQ handling for single irq drivers/mmc/core/sdio_irq.c | 33 - include/

Re: Optimized kernel memcpy/memset

On Thu, 5 May 2011, Måns Rullgård wrote: > David Gilbert writes: > > >> The memcpy case is not interesting.  Not at all.  Most kernel memcpy > >> calls are for small size copies.  The large copy instances are just bad > >> and misdesigned in the first place if they rely on memcpy (maybe they > >

Re: Optimized kernel memcpy/memset

David Gilbert writes: > On 5 May 2011 18:44, Måns Rullgård wrote: > >> The relative performance of NEON vs non-NEON seems to depend a lot on >> the size (relative to cache), alignment, and whether or not any >> prefetching (explicit PLD, automatic, or preload engine) is used. > > Yes, agreed - N

Re: Optimized kernel memcpy/memset

On 5 May 2011 18:59, Nicolas Pitre wrote: > On Thu, 5 May 2011, David Gilbert wrote: > >> If people believe it's worth breaking the context-switching taboo and >> putting a neon version into the kernel then yes I agree it's something >> you'd want to do as a build and/or runtime selection - but th

Re: Optimized kernel memcpy/memset

On 5 May 2011 18:44, Måns Rullgård wrote: > The relative performance of NEON vs non-NEON seems to depend a lot on > the size (relative to cache), alignment, and whether or not any > prefetching (explicit PLD, automatic, or preload engine) is used. Yes, agreed - Neon does very well in non-aligned

Re: Optimized kernel memcpy/memset

On Thu, 5 May 2011, Måns Rullgård wrote: > David Gilbert writes: > > > On 5 May 2011 17:45, Deepak Saxena wrote: > >> On May 05 2011, at 16:46, David Gilbert was caught saying: > >>> On 5 May 2011 16:08, Måns Rullgård wrote: > >>> > David Gilbert writes: > >>> >> Not quite: > >>> >>   a) Neon

Re: Optimized kernel memcpy/memset

On Thu, 5 May 2011, David Gilbert wrote: > If people believe it's worth breaking the context-switching taboo and > putting a neon version into the kernel then yes I agree it's something > you'd want to do as a build and/or runtime selection - but that's > quite a big taboo to break. There is n

RE: STM at UDS-Budapest

Zach, Unfortunately CCS Licenses are not free yet. To get a license you can either buy an XDS100 and use the free license that works with that or you can buy a CCS license from TI or a distributor. There is also a 90 day eval license that you can get here: http://processors.wiki.ti.com/index

Re: Optimized kernel memcpy/memset

On May 05 2011, at 16:46, David Gilbert was caught saying: > On 5 May 2011 16:08, Måns Rullgård wrote: > > David Gilbert writes: > >> Not quite: > >>   a) Neon memcpy/memset is worse on A9 than non-neon versions (better > >> on A8 typically) > > > > That is not my experience at all.  On the contr

Re: Optimized kernel memcpy/memset

David Gilbert writes: > On 5 May 2011 18:17, Måns Rullgård wrote: >> David Gilbert writes: >> >>> On 5 May 2011 16:08, Måns Rullgård wrote: David Gilbert writes: > Not quite: >   a) Neon memcpy/memset is worse on A9 than non-neon versions (better > on A8 typically)

Re: Optimized kernel memcpy/memset

David Gilbert writes: > On 5 May 2011 16:08, Måns Rullgård wrote: >> David Gilbert writes: >>> Not quite: >>>   a) Neon memcpy/memset is worse on A9 than non-neon versions (better >>> on A8 typically) >> >> That is not my experience at all.  On the contrary, I've seen memcpy >> throughput on A9

Re: Optimized kernel memcpy/memset

David Gilbert writes: > On 5 May 2011 17:45, Deepak Saxena wrote: >> On May 05 2011, at 16:46, David Gilbert was caught saying: >>> On 5 May 2011 16:08, Måns Rullgård wrote: >>> > David Gilbert writes: >>> >> Not quite: >>> >>   a) Neon memcpy/memset is worse on A9 than non-neon versions (bett

Re: Optimized kernel memcpy/memset

On 5 May 2011 18:17, Måns Rullgård wrote: > David Gilbert writes: > >> On 5 May 2011 16:08, Måns Rullgård wrote: >>> David Gilbert writes: Not quite:   a) Neon memcpy/memset is worse on A9 than non-neon versions (better on A8 typically) >>> >>> That is not my experience at all.  

another packaged kernel blueprint

Scott, It would be nice to have some landing team folks subscribe to https://blueprints.launchpad.net/ubuntu/+spec/linaro-platforms-o-kernel-leb-process I believe we have had some chaos at the end of both release cycles so far with trying to add additional features to the packaged kernel. It wo

Re: Optimized kernel memcpy/memset

On 5 May 2011 17:45, Deepak Saxena wrote: > On May 05 2011, at 16:46, David Gilbert was caught saying: >> On 5 May 2011 16:08, Måns Rullgård wrote: >> > David Gilbert writes: >> >> Not quite: >> >>   a) Neon memcpy/memset is worse on A9 than non-neon versions (better >> >> on A8 typically) >> >

Re: Optimized kernel memcpy/memset

On 5 May 2011 16:08, Måns Rullgård wrote: > David Gilbert writes: >> Not quite: >>   a) Neon memcpy/memset is worse on A9 than non-neon versions (better >> on A8 typically) > > That is not my experience at all.  On the contrary, I've seen memcpy > throughput on A9 roughly double with use of NEON

Linaro Ubuntu/Android LEB Star rating documentation blueprint

Hi As some of you know we have something called "Star rating" for supported boards. There are [1][2][3] pages on Linaro wiki which can be used as kind of base for understanding what is all about. We need to discuss what exactly our requirements mean and how to check are they supported - for that

Re: Optimized kernel memcpy/memset

David Gilbert writes: > Hi Kiko, > > On 5 May 2011 15:21, Christian Robottom Reis wrote: >> Hey there, >> >>    I was asked today in the board meeting about the use of NEON >> routines in the kernel; I said we had looked into this but hadn't done >> it because a) it wasn't conclusively better an

Re: Optimized kernel memcpy/memset

On 5 May 2011 17:57, Steve McIntyre wrote: > Technically it *can*, but you'll then have to be responsible for > dealing with all the extra register save/restores for context > switches. Normal wisdom is that it's just not worth that cost unless > you're doing an extended amount of such code (e.g.

Re: Optimized kernel memcpy/memset

On 5 May 2011 17:21, Christian Robottom Reis wrote: > Hey there, > >    I was asked today in the board meeting about the use of NEON > routines in the kernel; I said we had looked into this but hadn't done > it because a) it wasn't conclusively better and b) if better, it would > need to be done c

Re: What is upstreaming and why should we bother? Presentation @ LDS on May 12th at 10:00 local time.

Hi, The Android track has a similar session where we are going to discuss upstreaming to the Android project. https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-upstreaming We will discuss wha

Re: Optimized kernel memcpy/memset

On Thu, May 05, 2011 at 03:47:08PM +0100, David Gilbert wrote: >Hi Kiko, > >On 5 May 2011 15:21, Christian Robottom Reis wrote: >> Hey there, >> >>    I was asked today in the board meeting about the use of NEON >> routines in the kernel; I said we had looked into this but hadn't done >> it becaus

Re: Linaro 11.05 weekly testing 2011-05-05

Please note that for this week's test, the nano image has seen a significant drop in size. (~33M compressed, smaller than a hwpack now :-) If you run into a functional issue involving the nano image, please copy me on the bug so I can look into it ASAP! Regards, Tom On Thu, May 5, 2011 at 2:28 A

Re: Optimized kernel memcpy/memset

Hi Kiko, On 5 May 2011 15:21, Christian Robottom Reis wrote: > Hey there, > >    I was asked today in the board meeting about the use of NEON > routines in the kernel; I said we had looked into this but hadn't done > it because a) it wasn't conclusively better and b) if better, it would > need to

What is upstreaming and why should we bother? Presentation @ LDS on May 12th at 10:00 local time.

Hello all: Lee will be giving a talk about upstreaming in his electrifying presentation titled  "What is upstreaming and why should we bother?". The presentation [1]  is targeted at managers involved in such act or engineers who just started upstreaming, or want to do it. Please spread the work t

Optimized kernel memcpy/memset

Hey there, I was asked today in the board meeting about the use of NEON routines in the kernel; I said we had looked into this but hadn't done it because a) it wasn't conclusively better and b) if better, it would need to be done conditionally per-platform. But I wanted to double-check that's

Re: linaro-android track

On Thu, May 5, 2011 at 2:59 AM, Michael Hudson-Doyle wrote: > On Wed, 4 May 2011 09:30:53 +0300, Paul Sokolovsky > wrote: >> On Wed, 04 May 2011 11:40:50 +1200 >> Michael Hudson-Doyle wrote: >> that Android team's session can be merged into the above, >> https://blueprints.launchpad.net/linaro-

Linaro 11.05 weekly testing 2011-05-05

Hi, This is a message sent out once per week to call on our community to help test the Linaro evaluation builds we produce. If you have supported hardware, as found on: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/ please help our initiative by testing the official Linaro Evaluation