Closed GoogleCodeExporter closed 9 years ago
I'm seeing strange results on my device as well.
<6>[ 8070.839508] ramzswap: disk size not provided. You can use disksize_kb
module
param to specify size.
<6>[ 8070.839569] Using default: (25% of RAM).
<6>[ 8070.855102] ramzswap: disk size set to 24468 kB
<6>[ 8085.402343] Adding 24464k swap on /dev/ramzswap0. Priority:-1 extents:1
across:24464k SSD
# rzscontrol /dev/ramzswap0 -s
DiskSize: 25055232 kB
NumReads: 2204
NumWrites: 192
FailedReads: 0
FailedWrites: 2321
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 0
GoodCompress: 0 %
NoCompress: 0 %
PagesStored: 0
PagesUsed: 0
OrigDataSize: 0 kB
ComprDataSize: 0 kB
MemUsedTotal: 117 kB
# free
total used free shared buffers
Mem: 97876 96280 1596 0 164
Swap: 24464 2972 21492
Total: 122340 99252 23088
# cat /proc/swaps
Filename Type Size Used Priority
/dev/ramzswap0 partition 24464 3140 -1
Original comment by cgaik...@gmail.com
on 22 Jul 2009 at 2:08
Please provide following data:
- kernel logs
- kernel config
- /proc/meminfo
- /proc/cpuinfo
Original comment by nitingupta910@gmail.com
on 22 Jul 2009 at 2:11
I'm puzzled. Can you try 0.6pre2 so I know what code I should be looking at?
Maybe I
just committed some junk when you pulled it.
Original comment by nitingupta910@gmail.com
on 22 Jul 2009 at 2:23
Here ya go. This is with 0.6pre2. Stats looks the same as what I had pasted
earlier
running off the HG branch. The DiskSize output seems a bit odd too.
Original comment by cgaik...@gmail.com
on 22 Jul 2009 at 2:41
Attachments:
Just now I pushed changes that *may* solve this issue. Can you try this?
During compilation, You should get this warning: "Compiling on ARM".
Original comment by nitingupta910@gmail.com
on 22 Jul 2009 at 5:01
I'm still seeing the same behavior. Here are the other warnings during
compile, not
sure if they'd be relevant..
CC [M] /home/chris/android/src/compcache/ramzswap.o
/home/chris/android/src/compcache/ramzswap.c:35:2: warning: #warning "Compiling
on ARM"
/home/chris/android/src/compcache/ramzswap.c: In function
'ramzswap_set_disksize':
/home/chris/android/src/compcache/ramzswap.c:1237: warning: format '%lu'
expects type
'long unsigned int', but argument 3 has type 'size_t'
/home/chris/android/src/compcache/ramzswap.c: In function
'ramzswap_set_memlimit':
/home/chris/android/src/compcache/ramzswap.c:1284: warning: format '%lu'
expects type
'long unsigned int', but argument 3 has type 'size_t'
Original comment by cgaik...@gmail.com
on 22 Jul 2009 at 8:58
Fresh pull from hg and I get the same behavior as well.
Original comment by steve.ko...@gmail.com
on 22 Jul 2009 at 10:48
> Fresh pull from hg and I get the same behavior as well.
I had inserted warning/error messages for every case where write failure can
happen.
So, you must now have one of these messages in you logs. Can you upload logs
from
this latest test? And also the output of 'rzscontrol /dev/ramzswap0 --stats'.
If there are still no warn/error messages in logs then it might be possible that
somehow stats being reported are simply junk and compcache is actually working
fine.
I have this suspicion since "DiskSize" stat is showing weired values too.
Original comment by nitingupta910@gmail.com
on 23 Jul 2009 at 2:34
I found 1 issue with stats. The stats structure is 256 bytes which was being
allocated on kernel stack! This can cause stats corruption. Now it is
dynamically
allocated.
Original comment by nitingupta910@gmail.com
on 23 Jul 2009 at 3:33
Can you please try test version attached. Fixes include:
- Alloc ioctl stats dynamically.
- Flush cache for all uncompressed and zero filled pages too.
Original comment by nitingupta910@gmail.com
on 23 Jul 2009 at 10:21
Attachments:
Here's what I got with the 0.6_arm_test1. Not seeing any of the
warnings/errors in
the logs for write failures either.
# ./rzscontrol /dev/ramzswap0 --stats
DiskSize: 25055232 kB
NumReads: 122
NumWrites: 3
FailedReads: 0
FailedWrites: 132
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 0
GoodCompress: 0 %
NoCompress: 0 %
PagesStored: 0
PagesUsed: 0
OrigDataSize: 0 kB
ComprDataSize: 0 kB
MemUsedTotal: 9 kB
Original comment by cgaik...@gmail.com
on 23 Jul 2009 at 3:05
Attachments:
Extremely weird. If swap writes were actually failing then kernel will throw
out tons
of err/warnings - but we are not getting any such messages.
Put some memory load so it starts swapping to ramzswap. See if things crash.
Also
observer output of /proc/swaps - this would give some hint if rzs if actually
working
or not.
But how can we get junk in stats? I don't know yet - it all works fine on
x86/x64.
Your output shows DiskSize in bytes while we print it out in KB. This is just so
weird since its not some arbitrary junk either -- how can it suddenly "forget"
conversion to KB??
Original comment by nitingupta910@gmail.com
on 23 Jul 2009 at 3:24
haha I agree. It seems very odd and so far nothing is crashing. Swap does
seem to
fill up more quickly but that's just a guess. It's not filling fast enough to
say
for sure either way. I'll keep an eye on it and run some performance tests.
Steve's output showed the kilobytes instead of bytes, though. What could I
possibly
do differently that would cause that?
Original comment by cgaik...@gmail.com
on 23 Jul 2009 at 3:29
Alright... running from a fresh ramzswap each time, so 0 used. Ran mmap001
(http://www.arm.linux.org.uk/developer/stresstests.php) until it finished its
tests.
Here's the output at the end:
With 0.6
Filename Type Size Used Priority
/dev/ramzswap0 partition 24464 24392 -1
With 0.5.3:
Filename Type Size Used Priority
/dev/ramzswap0 partition 24464 16984 -1
Original comment by cgaik...@gmail.com
on 23 Jul 2009 at 3:55
I don't know why more swap is used with 0.6 but at least its seems to be working
fine. This narrows down the issue to stats corruption.
Original comment by nitingupta910@gmail.com
on 23 Jul 2009 at 4:10
I guess my only concern was that the app was consuming the same amount of
memory both
times and that I was seeing compression with .5 and no compression with .6.
I'll
have to do a little more digging in what the app is doing with memory though. I
don't even know if that's a possibility that ramz could be storing uncompressed
pages.
Original comment by cgaik...@gmail.com
on 23 Jul 2009 at 5:55
Can you please try test version attached? It makes stats structure packed and
aligned(4). It also prints out stats to kern log. If stats are correct in logs
but
not in direct output then it must be copy_to_user() which corrupting stats
structure.
Thanks,
Nitin
Original comment by nitingupta910@gmail.com
on 24 Jul 2009 at 4:35
Attachments:
Looks like you were right. The --stats output is still bad but here's the
output
from the kernel logs:
<6>[54161.862152] DiskSize: 24468 kB
<6>[54161.865753] NumReads: 157
<6>[54161.865783] NumWrites: 1627
<6>[54161.865783] FailedReads: 0
<6>[54161.865783] FailedWrites: 0
<6>[54161.865783] InvalidIO: 0
<6>[54161.865783] PagesDiscard: 0
<6>[54161.865814] ZeroPages: 68
<6>[54161.865814] GoodCompress: 65 %
<6>[54161.865814] NoCompress: 5 %
<6>[54161.865814] PagesStored: 1559
<6>[54161.865844] PagesUsed: 626
<6>[54161.865844] OrigDataSize: 6236 kB
<6>[54161.865844] ComprDataSize: 2404 kB
<6>[54161.865844] MemUsedTotal: 2504 kB
Original comment by cgaik...@gmail.com
on 24 Jul 2009 at 5:16
Original comment by nitingupta910@gmail.com
on 30 Jul 2009 at 2:58
Another try:
I just submitted change to now allocate rzscontrol stats on heap. This *might*
resolve the issue if allocation on stack was giving us unaligned pointer.
Please try latest commit. It prints some debug messages on stdout - so, please
post
output of rzscontrol and also the kernel log.
Original comment by nitingupta910@gmail.com
on 30 Jul 2009 at 5:44
/system/lib/modules # rzscontrol /dev/block/ramzswap0 --stats
debug: ret=0, stats_addr=0xb008, stats_sz=252
debug: 38368, 0, 0, 25051136
DiskSize: 0 kB
NumReads: 0
NumWrites: 52
FailedReads: 0
FailedWrites: 422
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 0
GoodCompress: 0 %
NoCompress: 0 %
PagesStored: 0
PagesUsed: 0
OrigDataSize: 0 kB
ComprDataSize: 0 kB
MemUsedTotal: 50 kB
Original comment by steve.ko...@gmail.com
on 31 Jul 2009 at 5:29
[deleted comment]
[deleted comment]
I can now reproduce this issue on qemu ARM emulator! Lets hope we'll find this
fix soon.
Original comment by nitingupta910@gmail.com
on 31 Jul 2009 at 2:45
Now it works correctly, at least on QEMU ARM emulator. Can you please confirm
if it
works correctly on actual h/w too? Thanks!
Output from emulator:
DiskSize: 31608 kB
NumReads: 170544
NumWrites: 170956
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 64491
ZeroPages: 190
GoodCompress: 98 %
NoCompress: 0 %
PagesStored: 7711
PagesUsed: 255
OrigDataSize: 30844 kB
ComprDataSize: 947 kB
MemUsedTotal: 1020 kB
Original comment by nitingupta910@gmail.com
on 2 Aug 2009 at 6:18
Working great on an actual G1:
/ # rzscontrol /dev/block/ramzswap0 -s
DiskSize: 24464 kB
NumReads: 102
NumWrites: 557
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 52
GoodCompress: 87 %
NoCompress: 1 %
PagesStored: 505
PagesUsed: 132
OrigDataSize: 2020 kB
ComprDataSize: 517 kB
MemUsedTotal: 528 kB
Thanks!!!!
Original comment by steve.ko...@gmail.com
on 3 Aug 2009 at 5:01
Original comment by nitingupta910@gmail.com
on 3 Aug 2009 at 5:15
Original issue reported on code.google.com by
steve.ko...@gmail.com
on 22 Jul 2009 at 2:02