On Mon, 30 Jan 2017 21:08:24 +0100 Marc-François LUCCA-DANIAU <mfld.fr@xxxxxxxxx> wrote: > Thanks Georg for the notes, I captured them in the file > /elks/elks/Documentation/text/networking.txt, that will be part of my > next commit. If people are capturing ideas for fixing things there are two things I've learned I wish I had known when I started ELKS. 1. Having a whole load of separate kernel stacks for each process all mapped into kernel memory is a mistake. It turns out you get near enough the same performance if keep the other kernel stacks in far memory and "every" process has a stack (and possibly a fixed struct of objects you reference a lot) that when in kernel is actually at the same place. When you idle you sit in the idle loop (spinning executing hlt) and if you schedule something other than idling to leave that you far memcpy the old task stack out into task private memory and far copy the new one in. That has two results. One (the important one for ELKS) is that all of a sudden you've got *loads* of kernel data memory free and two (not so big a deal for 8086), lots of references cease being foo->bar and become static. 8086 is pretty good at pointers so it's not as big a deal there. It slows task switching a tiny bit, but a single user box doesn't task switch much except between idle and the previous task. On the other hand the large amount of extra free kernel data space means more buffers and drivers and rapidly turns it into a win even on performance. 2. The commercial 8086 Unix platforms actually didn't preallocate memory or do chmem like hacks. Instead each process got allocated two chunks of memory. CS pointed to the code one (which may be shared) and the code runs from CS:0000 to CS:whatever. The clever bit is that the data segment stretches from DS:0000 to DS:brk and stack from DS:sp to DS:FFFF. That means each data/stack segment is always 64K long. However rather than waste that memory the memory allocator actually interleaved processes - that is the space between DS:brk and DS:sp of one process might be the code or data of another. This means they could always grow by swapping out/moving another task when either the brk/sbrk() grew memory or the compiler assisted stack pointer checking called the kernel to grow the stack. Alan -- 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
