Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 22 Jun 2002 18:35:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 22 Jun 2002 18:35:45 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:36209 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id ; Sat, 22 Jun 2002 18:35:43 -0400 To: Larry McVoy Cc: Linus Torvalds , Cort Dougan , Benjamin LaHaise , Rusty Russell , Robert Love , Linux Kernel Mailing List Subject: Re: latest linus-2.5 BK broken References: <20020621105055.D13973@work.bitmover.com> <20020622122656.W23670@work.bitmover.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: 22 Jun 2002 16:25:29 -0600 In-Reply-To: <20020622122656.W23670@work.bitmover.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4318 Lines: 91 Larry McVoy writes: > On Sat, Jun 22, 2002 at 12:25:09PM -0600, Eric W. Biederman wrote: > > To specifics, I don't see the point of OSlets on a single cpu that is > > hyper threaded. Traditional threading appears to make more sense to > > me. Similarly I don't see the point in the 2-4 cpu range. > > In general I agree with you here, but I think you haven't really considered > all the options. I can see the benefit on a *single* CPU. There are all > sorts of interesting games you could play in the area of fault tolerance > and containment. Imagine a system, like what IBM has, that runs lots of > copies of Linux with the mmap sharing turned off. ISPs would love > it. Hmm. Perhaps. But you are fundamentally susceptible to the base kernel, and the hardware on the machine. > Jeff Dike pointed out that if UML can run one kernel in user space, why > not N? And if so, the OS clustering stuff could be done on top of > UML and then "ported" to real hardware. I think that's a great idea, > and you can carry it farther, you could run multiple kernels just for > fault containment. See Sun's domains, DEC's Galaxy. Right. A clustered environment is accessible. For the most part I don't have a problem (except check pointing) that is facilitated by running linux under linux. Currently my problem to solve is compute clusters. My current worries are not can I scale a kernel to 64 cpus. My practical worries are will my user space to 1000 dual processor machines. The important point for me is that there are a fair number of fundamentally hard problems to get multiple kernels look like one. Especially when you start with a maximum decoupling. And you seem to assume that solving these problems are trivial. Maybe it is maintainable when you get done but there is a huge amount of work to get there. I haven't heard of a distributed OS as anything other than a dream, or a prototype with scaling problems. > > Given that there are some scales when you don't want/need more than > > one kernel, who has a machine where OSlets start to pay off? They > > don't exist in commodity hardware, so being proactive now looks > > stupid. > > Not as stupid as having a kernel noone can maintain and not being able > to do anything about it. There seems to be a subthread of elitist macho > attitude along the lines of "oh, it won't be that bad, and besides, > if you aren't good enough to code in a fine grained locked, soft real > time, preempted, NUMA aware, then you just shouldn't be in the kernel". > I'm not saying you are saying that, but I've definitely heard it on > the list. Hmm. I see a bulk of the on-going kernel work composed of projects to make the whole kernel easier to maintain. Especially interesting is the work that makes drivers relatively easy, and free from all of this cruft. Running some numbers (wc -l kernel/*.c fs/*.c mm/*.c) 1.2.12: 18813 lines 2.2.12: 37510 lines 2.5.14: 55701 lines So the core kernel is growing, but a fairly slow rate. Only worrying about the 60 thousand lines of generic kernel code is much better than worrying about the 3 million lines of driver code. And since you thought it was an interesting statistic: grep CONFIG_SMP kernel/*.c fs/*.c mm/*.c init/*.c | wc -l 44 So most of the code that cares about SMP is not in the core of the kernel, but is mostly the code that actually implements SMP support. So in thinking about I agree that the constant simplification work that is done to the linux kernel looks like one of the most important activities long term. > It's a great thing for bragging rights but it's a horrible thing from > the sustainability point of view. Given that the simplification efforts tend to be some of the highest priority activities in the kernel, and the easiest patches to get accepted. I don't get the feeling that we are walking into a long term maintenance problem. As for bragging rights, my kernel work tends to be some of the easiest code I have to write. I have no doubts that C is a high level programming language. Eric - 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/