lkml.org 
[lkml]   [2006]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] VM: I have a dream...
    On 1/31/06, Al Boldi <a1426z@gawab.com> wrote:
    > Faulty, because we are currently running a legacy solution to workaround an
    > 8,16,(32) arch bits address space limitation, which does not exist in
    > 64bits+ archs for most purposes.

    In the early 1990's (and maybe even the mid 90's), the typical hard
    disk's storage could theoretically be byte-addressed using 32-bit
    addresses -- just as (if I understand you correctly) you are arguing
    that today's hard disks can be byte-addressed using 64-bit addresses.

    If this was going to be practical ever (on commodity hardware anyway),
    I would have expected someone to try it on a 32-bit PC or Mac when
    hard drives were in the 100MB-3GB range... That suggests to me that
    there's a more fundamental reason (i.e. other than lack of address
    space) that caused people to stick with the current scheme.

    [snip]
    > There is a lot to gain, for one there is no more swapping w/ all its related
    > side-effects. You're dealing with memory only. You can also run your fs
    > inside memory, like tmpfs, which is definitely faster. And there may be
    > lots of other advantages, due to the simplified architecture applied.

    tmpfs isn't "definitely faster". Remember those benchmarks where Linux
    ext2 beat Solaris tmpfs?
    http://www.tux.org/lkml/#s9-12

    Also, the only way I see where "there is no more swapping" and
    "[y]ou're dealing with memory only" is if the disk *becomes* main
    memory, and main memory becomes an L3 (or L4) cache for the CPU [and
    as a consequence, main memory also becomes the main form of long-term
    storage]. Is that what you're proposing?

    If so, then it actually makes *less* sense to me than before -- with
    your scheme, you've reduced the speed of main memory by 100x or more,
    then you try to compensate with a huge cache. IOW, you've reduced the
    speed of *main* memory to (more or less) the speed of today's swap!
    Suddenly it doesn't sound so good anymore...

    --
    -Barry K. Nathan <barryn@pobox.com>
    -
    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: 2006-02-01 05:08    [W:0.023 / U:92.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site