Thread: [Development] kernel-power
View Single Post
maacruz is offline maacruz
2012-02-09 , 22:58
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#159
Originally Posted by freemangordon View Post
On the other hand those patches really seem like something useful, if there wasn't the problem they've introduced.

Is there a chance to build and test the kernel with those patches enabled and:

CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_DEBUG_MUTEXES=y

and/or similar (can't remember the exact flags for spinlock/mutex debugging) to see what is going on. I have bridgedriver debugging session to do here

BTW I have compcache swap, that might be the reason for reboots on my device.
I can try, but right now I'm looking at the patches and wondering what causes the problem:
0002-mtd should have no noticeable effect in the N900. If you look at the end of the patch...
Code:
/* This is used to handle contention on write/erase operations
    between partitions of the same physical chip. */
The N900 only uses one mtd partition, rootfs, so there can't be contention for accessing different partitions.

Now about 0001-mtd. It is a pretty straight forward patch, just replace all spinlocks with mutexes.
This patch shouldn't affect memory swapping because it takes place in mmc, not mtd, so the slowdown has to happen when a mmapped large file has been unmapped and then it is remapped again, a common scenario for executable files. Why the slowdown? The only reason I can think of is because the mutex has already been adquired.
If we look at the description text:
I have checked the code of the drivers and there is no use of atomic
pathes like interrupt or timers. The mtdoops facility will also not be used
by this drivers. So it is dave to replace the spin_lock against mutex.

There is no performance regression since the mutex is normally not
acquired.
Looking at the Nokia patches (2.6.28-omap1.diff) I see a lot of changes to the mtd subsystem, including a new mtd driver, so it is quite possible that the assumptions taken for this patch are wrong in the N900, requiring substantial rework.
Since it is doubtful that this patch could provide any noticeable gain in the N900, and it is confirmed that it causes problems, and it would require a lot of work, I think it is better just to drop them.
Last edited by maacruz; 2012-02-09 at 23:13.
 

The Following 2 Users Say Thank You to maacruz For This Useful Post: