Re: what's next for the linux kernel?

From: D. Hazelton (dhazelton_at_enter.net)
Date: 10/03/05

  • Next message: Paul Jackson: "Re: [PATCH 00/07][RFC] i386: NUMA emulation" 
    To: Vadim Lobanov <vlobanov@speakeasy.net>
Date:	Sun, 2 Oct 2005 23:14:46 +0000

    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 ***.", 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

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

  • Next message: Paul Jackson: "Re: [PATCH 00/07][RFC] i386: NUMA emulation"
    • Quantcast