Re: what's next for the linux kernel?

["D. Hazelton" <dhazelton@enter.net>]

[-- Attachment #1.1: Type: text/plain, Size: 6738 bytes --]

On Monday 03 October 2005 02:31, Vadim Lobanov wrote:
> On Mon, 3 Oct 2005, Luke Kenneth Casson Leighton wrote:
> > On Sun, Oct 02, 2005 at 06:20:38PM -0700, Vadim Lobanov wrote:
> > > On Mon, 3 Oct 2005, Luke Kenneth Casson Leighton wrote:
> > > > On Sun, Oct 02, 2005 at 04:37:52PM -0700, Vadim Lobanov wrote:
> > > > > >  what if, therefore, someone comes up with an
> > > > > > architecture that is better than or improves greatly upon
> > > > > > SMP?
> > > > >
> > > > > Like NUMA?
> > > >
> > > >  yes, like numa, and there is more.
> > >
> > > The beauty of capitalization is that it makes it easier for
> > > others to read what you have to say.
> >
> >  sorry, vadim: haven't touched a shift key in over 20 years.
>
> It's not going to bite you. I promise.

You never know - someone might've rigged his keyboard to shock him 
every time the shift key was pressed :)

<snip>
> > > >  the message passing system is designed as a parallel message
> > > > bus - completely separate from the SMP and NUMA memory
> > > > architecture, and as such it is perfect for use in
> > > > microkernel OSes.
> > >
> > > You're making an implicit assumption here that it will benefit
> > > _only_ microkernel designs.
> >
> >  ah, i'm not: i just left out mentioning it :)
> >
> >  the message passing needs to be communicated down to manage
> >  threads, and also to provide a means to manage semaphores and
> >  mutexes: ultimately, support for such an architecture would
> >  work its way down to libc.
> >
> >
> >  and yes, if you _really_ didn't want a kernel in the way at all,
> > you could go embedded and just... do everything yourself.
> >
> >  or port reactos, the free software reimplementation of nt,
> >  to it, or something :)
> >
> >  *shrug*.
>
> No, for reliability and performance reasons, I very much want a
> kernel in the way. After all, kernel code is orders of magnitude
> better tuned than almost all userland code.
>
> The point I was making here is that, from what I can see, the
> current Linux architecture is quite alright in anticipation of the
> hardware that you're describing. It _could_ be better tuned for
> such hardware, sure, but so far there is no need for such work at
> this particular moment.

Wholly agreed. The arguments over the benefits of running a 
microkernel aren't ever really clear. Beyond that, I personally feel 
that the whole micro vs. mono argument is a catfight between 
academics. I'd rather have a system that works and is proven than a 
system that is bleeding edge and never truly stable.  To me this 
means a monolithic kernel - microkernels are picky at best, and can 
be highly insecure (and that means "unstable" in my book too).

<snip>
> > > >  however, as i pointed out, 90nm and approx-2Ghz is pretty
> > > > much _it_, and to get any faster you _have_ to go parallel.
> > >
> > > Sure, it's going to stop somewhere, but you have to be a heck
> > > of a visionary to predict that it will stop _there_.
> >
> >  okay, i admit it: you caught me out - i'm a mad visionary.
> >
> >  but seriously.
> >
> >  it won't stop - but the price of 90nm mask charges, at approx
> >  $2m, is already far too high, and the number of large chips
> >  being designed is plummetting like a stone as a result - from
> >  like 15,000 per year a few years ago down to ... damn, can't
> > remember - less than a hundred (i think!  don't quote me on
> > that!)
> >
> >  when 90 nm was introduced, some mad fabs wanted to make 9
> >  metre lenses, dude!!! until carl zeiss were called in and
> >  managed to get it down to 3 metres.
> >
> >  and that lens is produced on a PER CHIP basis.
> >
> >  basically, it's about cost.
>
> I can guarantee one thing here -- the cost, as is, is absolutely
> bearable. These companies make more money doing this than they
> spend in doing it, otherwise they wouldn't be in business. From an
> economics perspective, this industry is very much alive and well,
> proven by the fact that these companies haven't bailed out of it
> yet.

I have to agree. And he is also completely ignoring the fact that both 
Intel and AMD are either in the process of moving to (or have moved 
to)  a 65nm fab process - last news I saw about this said both 
facilities were running into the multi-billion dollar cost range. 
Companies worried about $2m for a mask charge wouldn't be investing 
multiple billions of dollars in new plants and a new, smaller fab 
process.

<snip>
> > > >  and the drive for "faster", "better", "more sales" means
> > > > more and more parallelism.
> > > >
> > > >  it's _happening_ - and SMP ain't gonna cut it (which is why
> > > >  these multi-core chips are coming out and why hyperthreading
> > > >  is coming out).
> > >
> > > "Rah, rah, parallelism is great!" -- That's a great slogan,
> > > except...
> > >
> > > Users, who also happen to be the target of those sales, care
> > > about _userland_ applications. And the bitter truth is that the
> > > _vast_ majority of userland apps are single-threaded. Why? Two
> > > reasons -- first, it's harder to write a multithreaded
> > > application, and second, some workloads simply can't be
> > > expressed "in parallel". Your kernel might (might, not will)
> > > run like a speed-demon, but the userland stuff will still be
> > > lackluster in comparison.
> > >
> > > And that's when your slogan hits a wall, and the marketing hype
> > > dies. The reality is that parallelism is something to be
> > > desired, but is not always achievable.
> >
> >  okay: i will catch up on this bit, another time, because it is
> > late enough for me to be getting dizzy and appearing to be drunk.
> >
> >  this is one answer (and there are others i will write another
> > time. hint: automated code analysis tools, auto-parallelising
> > tools, both offline and realtime):
>
> We don't need hints. We need actual performance statistics --
> verifiable numbers that we can point to and say "Oh crap, we're
> losing." or "Hah, we kick butt.", as the case may be.

Hear, hear!  I'm still working my way through the source tree and 
learning the general layout and functionality of the various bits, 
but in just a pair of months of being on this list I can attest to 
the fact that one thing all developers seem to ask for is statistics.

<snip>
> At the risk of stepping on some toes, I believe that hyperthreading
> is going out of style, in favor of multi-core processors.

Agreed. And multi-core processors aren't really new technology - there 
have been multi-core designs out for a while, but those were usually 
low production "research" chips.

DRH

[-- Attachment #1.2: 0xA6992F96300F159086FF28208F8280BB8B00C32A.asc --]
[-- Type: application/pgp-keys, Size: 1365 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]