[Ovmsdev] Revised memory diagnostics code

Thu Nov 2 21:56:20 HKT 2017

Pretty much as expected. The big hit is the stack (4096 bytes). That may be able to be reduced, but needs tuning.

We can actually do away with the vehicle task, and call the vehicle module callbacks directly from the CAN task. But, doing it with two separate tasks and a queue between them should help with response time for incoming CAN frames. It also allows the vehicle task to do other things. Anyway, any changes we make there are localised with vehicle.{h,cpp} and don’t affect the individual vehicle module implementations.

Regards, Mark.

> On 2 Nov 2017, at 6:20 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> I've added a small fix to reenable building without memory debugging.
> 
> The base footprint of a vehicle module is…
> 
> 
> OVMS > vehicle module NONE
> I (31916) v-none: Generic NONE vehicle module
> OVMS > module memory AsyncConsole
> ============================
> Free 8-bit 35536/217576, 32-bit 16680/43464, blocks dumped = 18
> task=AsyncConsole    total=      0   5556  26120 change=     +0 
> +5556     +0
> task=tiT             total=    288   1080      0 change=     +0   
> +52     +0
> ============================
>  t=AsyncConsole s= 920 a=0x4009bb34  4009BAF8 82000398 3FFED17C
> 00000000 00000000 00006608 00000000 000015B4
>  t=AsyncConsole s=  60 a=0x4009baf8  4009B6AC 8200003C 3FFED17C
> F1E5C23B CD106DF9 9CE8BA4A 3BAEA0BA CEC251D4
>  t=AsyncConsole s=1100 a=0x4009b6ac  400987B8 8200044C 3FFED17C
> 3FFED1B4 00000011 00000001 00000005 00000005
>  t=AsyncConsole s=12020 a=0x400987b8  400958C4 82002EF4 3FFED17C
> 3FFEDCB0 01000034 3FFED17C 3FFED968 01000030
>  t=AsyncConsole s=12020 a=0x400958c4  3FFF6494 82002EF4 3FFED17C
> 4009BB34 02000398 3FFED17C 4009BAF8 0200003C
> ----------------------------
> + t=AsyncConsole s=  52 a=0x3ffedcb0  3FFED968 81000034 3FFCF230
> 3FFCF37C 3FFEDC78 1A2B3C4D 1A2B3C4D 3FFDD7B8
> + t=AsyncConsole s=  48 a=0x3ffed968  3FFEDC70 81000030 40193328
> 00000000 3FFED5D4 BF2C7602 0064D3E9 ADBEEF00
> + t=AsyncConsole s=  64 a=0x3ffedc70  3FFED948 81000040 3F40A9A8
> 3FFEDC84 00000007 69686576 00656C63 3A6D6F63
> + t=AsyncConsole s=  32 a=0x3ffed948  3FFED928 81000020 3FFCF2FC
> 3FFCF45C 3FFED8F0 1A2B3C4D 1A2B3C4D 3FFED17C
> + t=AsyncConsole s=  32 a=0x3ffed928  3FFED8E8 81000020 40193328
> 00000000 3FFED5D4 1A2B3C4D 1A2B3C4D 3FFED17C
> + t=AsyncConsole s=  64 a=0x3ffed8e8  3FFED890 81000040 3F40A9A8
> 3FFED8FC 00000007 69686576 00656C63 01742513
> + t=AsyncConsole s=  48 a=0x3ffed890  3FFED7E4 81000030 3FFE3140
> 3FFE3220 3FFED858 00E00409 BEEFFB00 3FFCDEAD
> + t=AsyncConsole s=  56 a=0x3ffed7e4  3FFED850 81000038 400ECED8
> 00000000 3FFED5D4 40173E7C 00000000 00BBA54A
> + t=AsyncConsole s=  64 a=0x3ffed850  3FFF75B0 81000040 3F40A9A8
> 3FFED864 00000007 69686576 00656C63 0038001A
> + t=AsyncConsole s= 380 a=0x3fff75b0  3FFF659C 8100017C 3FFF73E0
> 3FFF7540 F121C6CB 3FFD6E54 3FFC2FF0 3FFF75B8
> + t=AsyncConsole s=4116 a=0x3fff659c  3FFF6094 81001014 A5A5A5A5
> A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
> + t=AsyncConsole s= 504 a=0x3fff6094  3FFED5CC 810001F8 3FFF60F0
> 3FFF6280 3FFF60F0 3FFF626C 00000000 3FFF60B4
> + t=AsyncConsole s=  96 a=0x3ffed5cc  4009BB34 81000060 3F408088
> 00000000 00000000 00000000 3FFF609C 3FFF75B8
> ============================
> 
> 
> … 5608 bytes (5328 w/o debugging overhead).
> 
> It seems the list output is sorted LIFO, i.e. the 96 byte allocation
> (sizeof(OvmsVehicle) + 20) was the first here.
> 
> The 504 (484) block is the CAN rx queue, the 4116 (4096) & 380 (360)
> bytes are the CAN rx task stack & control structs.
> 
> The small allocations following seem to be some std::strings, haven't
> tracked them down yet. Not all of them get freed on unloading the
> vehicle module.
> 
> 
> Regards,
> Michael
> 
> 
> Am 02.11.2017 um 06:27 schrieb Stephen Casner:
>> Some more info about the revised memory diagnostics.
>> 
>> You can get a list of blocks owned by any of the tasks by specifying
>> one or more task names or ids on the module memory command.  The
>> output shows the task name, block size, block address, and the eight
>> words of the block (the first two being the malloc header):
>> 
>> OVMS > module memory wifi
>> ============================
>> Free 8-bit 64132/245712, 32-bit 16648/43432, blocks dumped = 10
>> ============================
>>  t=wifi s= 180 a=0x3ffe67c0  3FFE670C 810000B4 00000002 00000000 00000000 00000000 00000000 00000000
>>  t=wifi s= 180 a=0x3ffe670c  3FFE643C 810000B4 00000006 00000000 00000002 00000000 00000000 00000000
>>  t=wifi s=  56 a=0x3ffe643c  3FFE63E8 81000038 00000000 00000000 00000000 00000000 00000000 00000000
>>  t=wifi s=  84 a=0x3ffe63e8  3FFE64D4 81000054 00000006 00000000 00000000 00060004 00000000 00000004
>>  t=wifi s= 620 a=0x3ffed240  3FFED068 8100026C 3FFED070 FFFFFFFF 0000FFFF 00000000 00000000 00000000
>>  t=wifi s= 472 a=0x3ffed068  3FFED7EC 810001D8 00000000 FFFFFFFF 033A0279 00000000 401467AC 00000000
>>  t=wifi s= 104 a=0x3ffed7ec  3FFECE78 81000068 00000000 00000000 3FFED7F4 00000000 00000000 3FFED80C
>>  t=wifi s= 380 a=0x3ffece78  3FFEC064 8100017C 3FFECCD0 3FFECE00 5320B35D 3FFD00C8 3FFCC0D4 3FFECE80
>>  t=wifi s=3604 a=0x3ffec064  3FFEBFAC 81000E14 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
>>  t=wifi s= 184 a=0x3ffebfac  3FFEBF44 810000B8 3FFEC008 3FFEC058 3FFEC010 3FFEC00C 00000000 3FFEBFCC
>> ============================
>> 
>> If this command is given before and after some action then the later
>> result will separate the blocks into three lists: those freed since
>> the previous command, those that are still allocated, and those that
>> have been newly allocated since the previous command.  These are
>> prefixed by '-', ' ', and '+', respectively.
>> 
>> The "blocks dumped" value on the first line of the output tells how
>> many blocks were found when the command was issued.  The space set
>> aside to receive the list of blocks (allocated from 32-bit IRAM) is
>> limited to 1000 blocks.  If that limit is hit then some blocks will
>> not be shown.
>> 
>> In the previous implementation of the memory diagnostics, the blocks
>> for all tasks were dumped from the OS to the app storage and the total
>> space for each task was calculated in the app.  Hence, if there had
>> been more than 1000 blocks allocated the totals would not be correct.
>> There was an example of this in Mark's message about RAM use for
>> metrics structures:
>> 
>>> OVMS > module memory
>>> ============================
>>> Free 8-bit 85800/246632, 32-bit 18576/43548, numafter = 1000
>> In the revised implementation the totaling is done in the OS and
>> reported to the app separately from the list of blocks, and only the
>> blocks belonging to the selected tasks are returned.  That should make
>> hitting the limit less likely.
>> 
>>                                                        -- Steve
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev