lkml.org 
[lkml]   [2002]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lse-tech] Re: 10.31 second kernel compile

    On Sat, 16 Mar 2002, Daniel Phillips wrote:
    >
    > I meant that the functions are hardwired to the tree structure, which they
    > certainly are

    Oh yes.

    Sure, you can abstract the VM stuff much more - and many people do, to the
    point of actually having a per-architecture VM with very little shared
    information.

    The thing I like about the explicit tree is that while it _is_ an abstract
    data structure, it's also a data structure that people are very aware of
    how it maps to the actual hardware, which means that the abstraction
    doesn't come with a performance penalty.

    (There are two kinds of performance penalties in abstractions: (a) just
    the translation overhead for compilers etc, and (b) the _mental_ overhead
    of doing the wrong thing because you don't think of what it actually means
    in terms of hardware).

    Now, the linux tree abstraction is obviously _so_ close to a common set of
    hardware that many people don't realize at all that it's really meant to
    be an abstraction (albeit one with a good mapping to reality).

    > It could be a lot more abstract than that. Chuck Cranor's UVM (which seems
    > to bear some sort of filial relationship to the FreeBSD VM) buries all
    > accesses to the page table behind a 'pmap' API, and implements the standard
    > Unix VM semantics at the 'memory object' level.

    Who knows, maybe we'll change the abstraction in Linux some day too..
    However, I personally tend to prefer "thin" abstractions that don't hide
    details.

    The problem with the thick abstractions ("high level") is that they often
    lead you down the wrong path. You start thinking that it's really cheap to
    share partial address spaces etc ("hey, I just map this 'memory object'
    into another process, and it's just a matter of one linked list operation
    and incrementing a reference ount").

    Until you realize that the actual sharing still implies a TLB switch
    between the two "threads", and that you need to instantiate the TLB in
    both processes etc. And suddenly that instantiation is actually the _real_
    cost - and your clever highlevel abstraction was actually a lot more
    expensive than you realized.

    [ Side note: I'm very biased by reality. In theory, a non-page-table based
    approach which used only a front-side TLB and a fast lookup into higher-
    level abstractions might be a really nice setup. However, in practice,
    the world is 99%+ based on hardware that natively looks up the TLB in a
    tree, and is really good at it too. So I'm biased. I'd rather do good
    on the 99% than care about some theoretical 1% ]

    Linus

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

    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:0.045 / U:30.376 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site