Re: Elks networking

Alan Cox
2017-01-30T21:59:09Z

On Mon, 30 Jan 2017 21:08:24 +0100
Marc-Fran√ßois LUCCA-DANIAU <mfld.fr@gmail.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html