[lkml]   [2006]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Idea about a disc backed ram filesystem
    Matheus Izvekov <> wrote:
    > On 6/8/06, Horst von Brand <> wrote:
    > > tmpfs does use swap currently. Giving tmpfs a dedicated swap space is dumb,
    > > as it takes away the possibility of using that space for swapping when not
    > > in use by tmpfs (and viceversa).

    > The idea is not dumb per se. Maybe you want your applications to swap
    > to one device (or not swap at all) and a tmpfs mount to swap to
    > another.

    Why? If one device is faster, you'd want to prefer that one for swapping
    /and/ tmpfs. If not, I don't see the point. Except for limiting maximal
    sizes of tmpfs or swap, but limiting the later doesn't make much sense (why
    go OOM even though swap /is/ available?), and the former can be set on mount.

    > For me at least it would make a difference.


    > I dont use swap at all, have enough ram for all my processes.

    What is your beef then?

    > And ive
    > seen that for some workloads, setting a temporary directory as tmpfs
    > gives huge speed improvements. But just occasionally, the space used
    > in this temp dir will not fit in my ram, so in this case swapping
    > would be fine. The problem is, currently there is no way to enforce
    > this.

    That is exactly how tmpfs works, and has worked that way from the
    beginning. If it doesn't for you, it is a bug to report.

    > Ditto for the fact that, when you have many swap devices set, each
    > with different performances, there is no way to give priorities/rules
    > to enforce who uses each device.

    There are priorities: See swapon(8). It has worked this way from day one
    (or for as long as I can remember, in any case). The "who gets to use swap
    and who doesn't" you can control partially via pinning processes to RAM or
    limiting their memory use.

    > When someone gets to implement those features,

    Done already, as far as it makes sense.

    > this wouldnt be needed
    > anymore.

    Case closed.

    > But that seems far away enough to justify a more immediate
    > workaround.

    On some level you /have/ to trust the system to do things right. It has
    much more detailed information (and better response time) than you could
    ever hope to get. Besides, adding even more knobs to fiddle just makes the
    system more complex (and thus bloated/slow) and harder to manage, for a
    limited gain in niche situations.
    Dr. Horst H. von Brand User #22616
    Departamento de Informatica Fono: +56 32 654431
    Universidad Tecnica Federico Santa Maria +56 32 654239
    Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-09 15:47    [W:0.025 / U:7.120 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site