From ea77e910bb07ec2ee17ed0bae65811698d905fc6 Mon Sep 17 00:00:00 2001 From: Alan Cox Date: Tue, 21 Jul 2015 21:33:36 +0100 Subject: [PATCH] micropack: state of play update, add thoughts on overlays --- Kernel/platform-micropack/README | 48 ++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/Kernel/platform-micropack/README b/Kernel/platform-micropack/README index 2be57600..f0e2aedc 100644 --- a/Kernel/platform-micropack/README +++ b/Kernel/platform-micropack/README @@ -6,3 +6,51 @@ Test environment for a very squashed build to see what we can achieve in Not a useful target, but memory testing stuff +Sizes of target blocks: + +syscall_exec16: + ~= 1300 bytes + +syscall_other: + ~= 2031 bytes + +syscall_fs2 + 3386 + but includes open (821) and flock(381) which can sleep + leaves 2184 + + +So overlaying syscalL_fs2/syscall_other/syscall_exec16 would save about 2K +and take us to 6800, still 5K short + +Overlaying them all onto syscall_fs would save about 5400 bytes total but +does mean we need to be smart about overlay restores on wakeup. That also +fixes open which would give us a total save of about 6.5K or close to the +6912 or so needed. The single tty hack would probably push us to the needed +size. + +However syscall_fs is only 1.9K so would need to split syscall_fs2 two ways + +Would give us + + syscall_fs + syscall_exec16 + syscall_other + syscall_fs2_a + syscall_fs2_b + +Other candidates for the bot which are big are waitpid at 380 bytes and +signal + sigdisp at 621 bytes the pair. signal/sigdisp normally occur only +at startup and signal handling so would be acceptable-ish, waitpid always +involves a task switch anyway. Neither are ideal but they might work. + +Other thoughts. When working with small app have a version of some of the +overlays that can be loaded in the top of app space - how to do relocations +and patches ? + +Do we want to keep the overlays in the swap space gapped between each +swapped app. Disk swap is usually cheap spacewise and it would speed up +their fetching (especially as most IDE drives cache at least a track!). +Would in a sense become a sneaky way to use the IDE cache as a secondary +memory 8) + -- 2.34.1