To: "David S. Miller" <davem@redhat.com>, torvalds@transmeta.com
Cc: davidm@hpl.hp.com, anton@samba.org, linux-kernel@vger.kernel.org,
        zippel@linux-m68k.org
Subject: Re: thread_info implementation
In-Reply-To: Message from "David S. Miller" <davem@redhat.com>
   of "Mon, 11 Feb 2002 18:51:00 PST." <20020211.185100.68039940.davem@redhat.com>
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 12 Feb 2002 13:21:10 +0000
Message-ID: <23729.1013520070@warthog.cambridge.redhat.com>
From: David Howells <dhowells@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org


"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/