)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000859,"name":"Karl Palsson","email":"karlp@tweak.au","username":"karlp"},"change_message_id":"a00f2a62e52c5de2de0f963564d584c5d5f2f460","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2f2ee929_1f0817e9","updated":"2024-06-29 22:12:26.000000000","message":"Is 2MB enough of a step up?  What\u0027s the behaviour when this goes badly? We\u0027re only allocation 4MB ram here now.  Can we just make this max bigger like 32MB? it\u0027s only used if the address space of the target app needs it right?","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1002278,"name":"bryghtlabs-richard","display_name":"Richard Allen","username":"bryghtlabs-richard","status":"Firmware at BryghtLabs. Also rsaxvc at home."},"change_message_id":"ae7206597c6dbf6f04bd5ccbfd80fbb16f8e265a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"411742ce_68b69a91","updated":"2024-07-31 15:34:08.000000000","message":"Perhaps we could use the basic-block GMON type to store raw PC samples instead of, or in addition to the histogram type?","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"7e27273c59f2509e015383646b261bd37dab6210","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"37cdafba_cef5e09a","updated":"2024-08-03 17:07:02.000000000","message":"please also check https://review.openocd.org/c/openocd/+/8405","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1002278,"name":"bryghtlabs-richard","display_name":"Richard Allen","username":"bryghtlabs-richard","status":"Firmware at BryghtLabs. Also rsaxvc at home."},"change_message_id":"a823c65e78710583563337e812710d23b9dbf439","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"cc4f995c_d4020d39","in_reply_to":"21531dcc_0f44b8d1","updated":"2024-07-30 16:50:36.000000000","message":"Karl, should I set it to 32MB for now?","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1002273,"name":"Richard Allen","email":"rsaxvc@gmail.com","username":"rsaxvc","status":"@BryghtLabs, @rsaxvc.net"},"change_message_id":"f3869d80edbdc9c0b87c1e70be2b68689bdf3779","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"21531dcc_0f44b8d1","in_reply_to":"2f2ee929_1f0817e9","updated":"2024-07-02 02:37:49.000000000","message":"\u003e Is 2MB enough of a step up?\n\nIt is for me, today, and we can make it 32MegaBuckets if preferred, but eventually it doesn\u0027t scale well, especially for virtual memory and discontinuous physical memory systems.\n\n\u003e What\u0027s the behaviour when this goes badly? \n\u003e it\u0027s only used if the address space of the target app needs it right?\n\nWhen the bucket-limit is hit, sometimes OpenOCD is prevented from consuming an excessive amount of memory. Ex: on SamD54, there is 8KB of backup RAM that can stay up while nearly everything else is off, but it\u0027s about 1GB of addresses away from the NOR code flash. Kinetis M4s have 512MB of code addresses, with their NOR starting at 0x0 and their executable RAM usually at the end of ICODE at 0x20000000.\n\nAnother approach would be to generate bucket-ranges dynamically, perhaps as soon as there is a large enough gap between addresses that were sampled to break it into a new range.","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"e7561c51eb25ae224666b79c3d3d75f02117de14","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b66fd083_d3c759bf","in_reply_to":"411742ce_68b69a91","updated":"2024-08-03 17:22:06.000000000","message":"I don\u0027t know about the raw PC samples, I\u0027m not too familiar with gmon format nor about the tools that will use it. It could be another way to provide the result, moving the processing of the histogram outside OpenOCD.\n\nWhat about extend the command syntax to support both current:\n`profile seconds filename start end`\nand extended:\n`profile seconds filename start end buckets [start end buckets [...]]`\nso separate regions can be well specified, together with each number of buckets.\nAlso, it could be interesting to change from the command line the max number of samples (currently 1M).","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1002273,"name":"Richard Allen","email":"rsaxvc@gmail.com","username":"rsaxvc","status":"@BryghtLabs, @rsaxvc.net"},"change_message_id":"93732979ae6ec3b152f423d635e3746d59a459f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"55a653c1_b6e02edd","in_reply_to":"8ee5add7_522493f3","updated":"2024-11-29 16:06:52.000000000","message":"This all gets a ton easier if we sort the PC samples first.\n\nThen we can iterate through the samples, encoding the histogram as we go. This way, if we set a max limit to something huge like 1GB, profiling a sparse-memory system will only generate a large file, but not require the histogram to be memory-resident.","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1002278,"name":"bryghtlabs-richard","display_name":"Richard Allen","username":"bryghtlabs-richard","status":"Firmware at BryghtLabs. Also rsaxvc at home."},"change_message_id":"fcc5bcd8d3ce94dd915f23a99d274c2499ece1e8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8ee5add7_522493f3","in_reply_to":"b66fd083_d3c759bf","updated":"2024-09-05 19:36:42.000000000","message":"Sorry, Antonio, I missed your comment until now. As long as there is hope of a better mechanism, I\u0027d prefer to look into handling bucketization or raw-sample-serialization automatically as time allows.\n\nThat said, specifying [(start,end,bucket)] could still be a useful feature, but I want to make the profiler work reasonably by default on these sparsely mapped cores if we can.\n\nI\u0027ve also had trouble finding documentation on the GMON format. I\u0027ve looked at programs for a few platforms, and sometimes they differ, or ignore different data types.\n\nKarl was correct in their concern - 2MB histogram was enough of a step up for the ARM core I was working on but was not enough for the ESP32-S3 I\u0027ve been working with.","commit_id":"5cbb2a45a75347ec461f50cf35c409fe735aa598"},{"author":{"_account_id":1002278,"name":"bryghtlabs-richard","display_name":"Richard Allen","username":"bryghtlabs-richard","status":"Firmware at BryghtLabs. Also rsaxvc at home."},"change_message_id":"fc63ff5eacd9d1d5202f8875f3e3ffb6468a14de","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"8abbc5d7_61865981","updated":"2025-02-06 19:43:06.000000000","message":"gmon.out compression through multi-histogram encoding patch is here https://review.openocd.org/c/openocd/+/8739/","commit_id":"ff0c3865ee2ced37dca578470a1eeee162ef8ea2"}]}