Messages in this thread | | | Date | Sun, 2 Jul 2000 16:43:09 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: a joint letter on low latency and Linux |
| |
Larry McVoy writes: > [somebody]
>> - Use Linus' trick of a multi threaded UP kernel using >> SMP locks (2.5 material), also hated by Larry/Victor. > > I don't know where you got that idea. Sun does the same thing and I've > always held it up as a good thing, ``eat what you cook'' type of deal. > The nice thing about doing that is that because of interrupts even a UP > is really an MP, and you don't have to have two different models when > doing SMP. > > So I don't hate it. I agree with Ted's comment that it would be nice if > it were possible to have it both ways so as to be able to quantify the > effects, though I don't know how realistic that is.
Digital UNIX (now Tru64, was OSF/1) uses self-modifying code to create a generic kernel that can do, if I remember right:
1. plain 2. real-time 3. SMP 4. real-time SMP 5. lock debugging
So, if you don't want these features, you only suffer some NOPs and perhaps sub-optimal register allocation. I suppose the x86 version of this could be a debug breakpoint byte followed by a byte to indicate the required operation -- lock, unlock, or whatever. One might also be able to make the assembler spit out addresses, like the exception table code does.
Other uses for this technique include: Generic kernels could run on a real i386 without being slow on a 486. Modules could work for SMP, huge memory, and normal kernels. Exact process accounting could be part of every kernel, but NOPed out at runtime if not enabled. Perhaps even RT-Linux could use this ability.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |