Comment 18 for bug 501715
Revision history for this message
| lavinog (lavinog) wrote Re: ureadahead doesn't reduce tracing buffer after profile | #18 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
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, or use
$ dmesg
to view your kernel log and look for "mmiotrace has lost events" warning. If
events were lost, the trace is incomplete. You should enlarge the buffers and
try again. Buffers are enlarged by first seeing how large the current buffers
are:
$ cat /sys/kernel/
gives you a number. Approximately double this number and write it back, for
instance:
$ echo 128000 > /sys/kernel/
Then start again from the top.
-------------------
The size of the trace buffer actually used can be determined with
wc -c /sys/kernel/
(The size will be in bytes)
So far I have seen sizes range from 2-30Mb
I have yet to check some of my larger systems, but it seems possible that 128M could be necessary in some cases.
...
I have found a hackish solution for recovering the memory after the profile.
First ensure the profile is complete (it waits a while even after you log in) by checking that the pack files exist. You should also check that they are somewhat recent too since I don't know if a reprofile triggered by age will remove these files.
You can then recover the memory by reducing the buffer size:
echo 2048|sudo tee /sys/kernel/
2048 was just an arbitrary size. You can use 1 if you really want to save memory.
I do not know of the consequences of resizing the buffer afterwards, but it seems to work fine.
@Scott: Could you provide some feedback if this is a reasonable solution for the time being?