Messages in this thread | | | Subject | Re: thread_info implementation | Date | Tue, 12 Feb 2002 13:21:10 +0000 | From | David Howells <> |
| |
"David S. Miller" <davem@redhat.com> wrote: > OK, so back to square one: why am I supposed to do all this work for > something that will likely slow things slightly down and, at best, > doesn't hurt performance? The old set up works great and as far as > I'm concerned, is not broken. > > It keeps your platform the same, and it does help other platforms. > It is the nature of any abstraction change we make in the kernel > that platforms have to deal with.
It wasn't all that big a change for the i386 arch either. Most of the changes to assembly actually involved cleaning up and various assembly sources and sharing constants (something that should probably have been done a lot earlier).
What might be worth doing is to move the task_struct slab cache and (de-)allocator out of fork.c and to stick it in the arch somewhere. Then archs aren't bound to have the two separate. So for a system that can handle lots of memory, you can allocate the thread_info, task_struct and supervisor stack all on one very large chunk if you so wish.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |