Memory backend improvements

#906 Merged at 7a3b5fa
Repository
Branch
memory-backend
Repository
Branch
unified
Author
  1. Alex
Reviewers
Description

Cherry-picked from experimental branches.

Everything from here is already included in lua_fix and crop_rec_4k builds, so you may test from there if you prefer. The result will be a bit different when compiling directly from this branch, as it doesn't have the experimental stuff, but the memory backend is pretty much the same. There are some experiments in exmem.c on the crop_rec_4k branch that I didn't include yet (mostly on the SRM allocator).

Changes can be noticed on:

  • Free Memory dialog (should autodetect the "shoot" entries faster)
  • press SET while on Allocated RAM to get more details (that graph now looks different)
  • memory benchmark (bench.mo) should now work on all models (in particular, 1100D and EOSM could not run it before, as it requires two 16MB blocks - not available from shoot_malloc on these models)
  • raw recording should start faster (as it no longer takes 1 second to autodetect how much memory we have)
  • torture test: old-style Lua on 1100D (it finally works!)
  • even with old-style Lua loaded, the memory benchmark (requiring 2x16MB) still runs on 1100D!

I can also get usage graphs from the debug messages printed from mem.c. There are two ways to get them:

  • in both cases, define MEM_DEBUG in mem.c
  • 1) use qprintf for dbg_printf (if unavailable, copy it from qemu-util.c and compile normally, without CONFIG_QEMU)
  • 2) define CONSOLE_DEBUG in console.c (log gets saved on the card under ML/LOGS)

Examples:

  • 1100D with old Lua (just loading the default scripts; bench.mo and adv_int.mo also loaded):

1100D-lua.png

  • 1100D with lua_fix (ran Hello World):

1100D-lua_fix.png

The torture test results (1100D with old lua) are attached to each changeset (as comment), so you can see how each change affected the results for this particular scenario.

How to test: any kind of power use that would push the memory backend beyond its limits (many module loaded, tests that allocate large amounts of memory or many small blocks etc), in particular on camera models with very little memory (1100D, EOSM, any other Rebels).

Comments (0)