After switching my phone from Donut to Eclair, I've been experiencing
a lot of performance issues. The phone will work well for a while but
after 15 or 20 minutes of clicking through the UI, it will become
almost completely unresponsive and mostly stay that way. The CPU usage
is pretty low, and there is about 35MB of cache with a few MB of free
RAM. I was using 2.6.29 on both Donut and Eclair, although they have
some modifications on top of that.

When watching `top`, I can see that there is a substantial amount of
IO wait (>50%) when I'm in this state. When I put 1 in block_dump and
watch /proc/kmsg, I see that most of the IO seems to be coming from
kswapd when I'm in this state (the phone doesn't have swap enabled).

I've been trying to figure out the root cause of this, and the two
best indicators that I've found so far are that:

- When I look at /proc/meminfo when I'm in this state, "Active(file)"
and "Inactive(file)" are very low compared to my Donut device (<2MB
versus ~20MB)
- When I run `echo 3 > /proc/sys/vm/drop_caches`, the lag immediately
goes away (for a while)

Could it be that pages are being stuck in the cache? Is there a way
for that to happen? I don't know how to see a good overview from the
cache, although I've been getting systemtap working on my device, so I
hope I can find a point to probe in the kernel to log this
information. The only other alternative to pages being stuck that I've
considered is that there is a setting, which dictates some min/max
amounts for the cache in terms of page cache vs file cache.

Does anyone have suggestions about what I could investigate to find
the root cause of this? I'm not familiar at all with the kernel, but
I've started reading through some of the page cache related code,
though I haven't learned much from that, yet.

Thank you

-- 
unsubscribe: [email protected]
website: http://groups.google.com/group/android-kernel

Reply via email to