I see 128000 kb was hardcoded into the source of ureadahead. I also see in
mmiotrace.txt where this is used as an example:
---
Check that mmiotrace did not lose events due to a buffer filling up. Either
$ grep -i lost mydump.txt
which tells you exactly how many events were lost, o
It was mentioned in this thread:
http://ubuntuforums.org/showthread.php?t=1434502
that once online profiling is implemented, this issue will go away.
I am wondering if a bug needs to be filed for the kernel because there
is nothing to indicate that the memory is being used for tracing memory.
Usi
Would like to hear a little feedback on this from the devs, why is this
still in Lucid, with an impending release. Just spend half a day
debugging my machine which was down to a crawl thanks to this, luckily
someone on the forums heard about this bug.
--
ureadahead doesn't reduce tracing buffer a
Just found out about /sys/kernel/debug/tracing/buffer_size_kb
It reads 128000 on my vm which is currently showing about 322M (tracing on)
182M (tracing off) diff=140M so it looks like it is the tracing buffer.
Some questions:
1. Why is it that no application can differentiate memory used by the
I have the same problem with kubuntu lucid beta1.
The only measure for me to reduce this high memory usage, is always
starting with an empty session and remove ureadahead.
Normally I like intelligent memory usage, but it´s not funny when my
system will be slower and slower when it begins to swap
I wrote my observations about the memory usage here:
http://ubuntuforums.org/showpost.php?p=9012493&postcount=55
I can confirm this phenomenon in both karmic and lucid.
--
ureadahead doesn't reduce tracing buffer after profile
https://bugs.launchpad.net/bugs/501715
You received this bug notifica
