Proposal submitted as PR #203: https://github.com/jbruchon/elks/pull/203 2018-04-26 15:17 GMT+02:00 Marc-François Lucca-Daniau <mfld.fr@xxxxxxxxx>: > Hello all the 8086 hobbyists, > > Here is a new design change proposal, coming from first thoughts about > the future implementation of a kind of TMPFS in ELKS. > > TMPFS would be the complement of the recently introduced ROMFS, that > targets embedded systems with kernel and RootFS in the Flash memory, > but without any write capability. > > It is intended for R/W folders like /tmp, /run, and /dev (for dynamic > device file creation), with many but very small or even empty files > (for devices). It could also be used as an initial RootFS in RAM in > the future. > > For a minimal footprint in memory, it should not allocate memory in > standard 512B / 1K blocks (like the RAMFS), but in small blocks of > paragraphs, aka segments. > > Today the memory manager (MM) stores the table of the free segments (= > holes) in the kernel space, with a maximum of 38 entries: > #define MAX_SEGMENTS 8+(MAX_TASKS*2) > #define MAX_TASKS 15 > > As space in kernel DS is limited, the proposal is to scatter that > table into the whole available memory, as the usual chained-list of > free & allocated segments (SLOB). > > The other table of the swapped segments would be kept in the kernel > DS, for an obvious reason :-). > > Pros: > - ability to allocate many small segments for TMPS inodes and file data > - more space in the kernel DS for additional features > > Cons: > - less efficient memory allocation (cost of list traversal) > - memory fragmentation, even with current best-fit algorithm > > To mitigate the cons, we could use later some well known & more > sophisticated memory allocation schemes (tree, buddy, SLAB, etc). But > as ELKS is more for educational / experimental purpose than for a > heavily loaded production environment :-P, I think it should be kept > simple. > > Any idea to improve the proposal is welcome, > > MFLD -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
