Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 11/06/05

  • Next message: Gustavo Guillermo Pérez: "Re: 2.6.14, udev: unknown symbols for ehci_hcd" 
    Date:	Sun, 6 Nov 2005 09:00:42 -0800 (PST)
To: Kyle Moffett <mrmacman_g4@mac.com>

    On Sun, 6 Nov 2005, Linus Torvalds wrote:
    >
    > And no standard hardware allows you to do that in hw, so we'd end up doing
    > a software page table walk for it (or, more likely, we'd have to make
    > "struct page" bigger).
    >
    > You could do it today, although at a pretty high cost. And you'd have to
    > forget about supporting any hardware that really wants contiguous memory
    > for DMA (sound cards etc). It just isn't worth it.

    Btw, in case it wasn't clear: the cost of these kinds of things in the
    kernel is usually not so much the actual "lookup" (whether with hw assist
    or with another field in the "struct page").

    The biggest cost of almost everything in the kernel these days is the
    extra code-footprint of yet another abstraction, and the locking cost.

    For example, the real cost of the highmem mapping seems to be almost _all_
    in the locking. It also makes some code-paths more complex, so it's yet
    another I$ fill for the kernel.

    So a remappable kernel tends to be different from a remappable user
    application. A user application _only_ ever sees the actual cost of the
    TLB walk (which hardware can do quite efficiently and is very amenable
    indeed to a lot of optimization like OoO and speculative prefetching), but
    on the kernel level, the remapping itself is the cheapest part.

    (Yes, user apps can see some of the costs indirectly: they can see the
    synchronization costs if they do lots of mmap/munmap's, especially if they
    are threaded. But they really have to work at it to see it, and I doubt
    the TLB synchronization issues tend to be even on the radar for any user
    space performance analysis).

    You could probably do a remappable kernel (modulo the problems with
    specific devices that want bigger physically contiguous areas than one
    page) reasonably cheaply on UP. It gets more complex on SMP and with full
    device access.

    In fact, I suspect you can ask any Xen developer what their performance
    problems and worries are. I suspect they much prefer UP clients over SMP
    ones, and _much_ prefer paravirtualization over running unmodified
    kernels.

    So remappable kernels are certainly doable, they just have more
    fundamental problems than remappable user space _ever_ has. Both from a
    performance and from a complexity angle.

                            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/

  • Next message: Gustavo Guillermo Pérez: "Re: 2.6.14, udev: unknown symbols for ehci_hcd"

    Relevant Pages

    • Re: [patch for 2.6.26 0/7] Architecture Independent Markers
      ... as far as the assembly for the markers in the fast path is ... cache footprint of the kernel quite substantially, ... slowpath cost. ... I like your tracing filters interface. ...
      (Linux-Kernel)
    • Re: [patch for 2.6.26 0/7] Architecture Independent Markers
      ... 96 bytes _per marker_ sprinkled throughout the kernel. ... slowpath cost. ...
      (Linux-Kernel)
    • Re: Generating a driver without DDK,...
      ... obviously means you've done very little driver development ... ... 15 Years of development i did a little on Kernel Space this is true! ... peice of crap you currently have will far exceed the cost of a new machine. ... thing as a stupid question". ...
      (microsoft.public.development.device.drivers)
    • Re: Generating a driver without DDK,...
      ... 15 Years of development i did a little on Kernel Space this is true! ... peice of crap you currently have will far exceed the cost of a new machine. ... thing as a stupid question". ... so let me ask you that sarcastic question: ...
      (microsoft.public.development.device.drivers)
    • Re: setuid root
      ... | potential past, current and future interpreters. ... That's a cost that _today_ is most certainly higher than the cost it was ... |>kernel and made to work with existing shells. ... and none at all in the several shell script interpreters". ...
      (comp.unix.programmer)