lkml.org 
[lkml]   [2007]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: -mm merge plans for 2.6.23
    On 7/23/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
    > Ray Lee wrote:
    > > That said, I'm willing to run my day to day life through both a swap
    > > prefetch kernel and a normal one. *However*, before I go through all
    > > the work of instrumenting the damn thing, I'd really like Andrew (or
    > > Linus) to lay out his acceptance criteria on the feature. Exactly what
    > > *should* I be paying attention to? I've suggested keeping track of
    > > process swapin delay total time, and comparing with and without. Is
    > > that reasonable? Is it incomplete?
    >
    > I don't feel it is so useful without more context. For example, in
    > most situations where pages get pushed to swap, there will *also* be
    > useful file backed pages being thrown out. Swap prefetch might
    > improve the total swapin delay time very significantly but that may
    > be just a tiny portion of the real problem.

    Agreed, it's important to make sure we're not being penny-wise and
    pound-foolish here.

    > Also a random day at the desktop, it is quite a broad scope and
    > pretty well impossible to analyse.

    It is pretty broad, but that's also what swap prefetch is targetting.
    As for hard to analyze, I'm not sure I agree. One can black-box test
    this stuff with only a few controls. e.g., if I use the same apps each
    day (mercurial, firefox, xorg, gcc), and the total I/O wait time
    consistently goes down on a swap prefetch kernel (normalized by some
    control statistic, such as application CPU time or total I/O, or
    something), then that's a useful measurement.

    > If we can first try looking at
    > some specific problems that are easily identified.

    Always easier, true. Let's start with "My mouse jerks around under
    memory load." A Google Summer of Code student working on X.Org claims
    that mlocking the mouse handling routines gives a smooth cursor under
    load ([1]). It's surprising that the kernel would swap that out in the
    first place.

    [1] http://vignatti.wordpress.com/2007/07/06/xorg-input-thread-summary-or-something/

    > Looking at your past email, you have a 1GB desktop system and your
    > overnight updatedb run is causing stuff to get swapped out such that
    > swap prefetch makes it significantly better. This is really
    > intriguing to me, and I would hope we can start by making this
    > particular workload "not suck" without swap prefetch (and hopefully
    > make it even better than it currently is with swap prefetch because
    > we'll try not to evict useful file backed pages as well).

    updatedb is an annoying case, because one would hope that there would
    be a better way to deal with that highly specific workload. It's also
    pretty stat dominant, which puts it roughly in the same category as a
    git diff. (They differ in that updatedb does a lot of open()s and
    getdents on directories, git merely does a ton of lstat()s instead.)

    Anyway, my point is that I worry that tuning for an unusual and
    infrequent workload (which updatedb certainly is), is the wrong way to
    go.

    > After that we can look at other problems that swap prefetch helps
    > with, or think of some ways to measure your "whole day" scenario.
    >
    > So when/if you have time, I can cook up a list of things to monitor
    > and possibly a patch to add some instrumentation over this updatedb
    > run.

    That would be appreciated. Don't spend huge amounts of time on it,
    okay? Point me the right direction, and we'll see how far I can run
    with it.

    > Anyway, I realise swap prefetching has some situations where it will
    > fundamentally outperform even the page replacement oracle. This is
    > why I haven't asked for it to be dropped: it isn't a bad idea at all.

    <nod>

    > However, if we can improve basic page reclaim where it is obviously
    > lacking, that is always preferable. eg: being a highly speculative
    > operation, swap prefetch is not great for power efficiency -- but we
    > still want laptop users to have a good experience as well, right?

    Absolutely. Disk I/O is the enemy, and the best I/O is one you never
    had to do in the first place.
    -
    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: 2007-07-24 18:17    [W:0.026 / U:32.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site