lkml.org 
[lkml]   [2007]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: The performance and behaviour of the anti-fragmentation related patches
    On Fri, 02 Mar 2007 17:34:31 -0500
    Rik van Riel <riel@redhat.com> wrote:

    > >>>> The main reason they end up pounding the LRU locks is the
    > >>>> swappiness heuristic. They scan too much before deciding
    > >>>> that it would be a good idea to actually swap something
    > >>>> out, and with 32 CPUs doing such scanning simultaneously...
    > >>> What kernel version?
    > >> Customers are on the 2.6.9 based RHEL4 kernel, but I believe
    > >> we have reproduced the problem on 2.6.18 too during stress
    > >> tests.
    > >
    > > The prev_priority fixes were post-2.6.18
    >
    > We tested them. They only alleviate the problem slightly in
    > good situations, but things still fall apart badly with less
    > friendly workloads.

    What is it with vendors finding MM problems and either not fixing them or
    kludging around them and not telling the upstream maintainers about *any*
    of it?

    > >> I have no reason to believe we should stick our heads in the
    > >> sand and pretend it no longer exists on 2.6.21.
    > >
    > > I have no reason to believe anything. All I see is handwaviness,
    > > speculation and grand plans to rewrite vast amounts of stuff without even a
    > > testcase to demonstrate that said rewrite improved anything.
    >
    > Your attitude is exactly why the VM keeps falling apart over
    > and over again.
    >
    > Fixing "a testcase" in the VM tends to introduce problems for
    > other test cases, ad infinitum.

    In that case it was a bad fix. The aim is to fix known problems without
    introducing regressions in other areas. A perfectly legitimate approach.

    You seem to be saying that we'd be worse off if we actually had a testcase.

    > There's a reason we end up
    > fixing the same bugs over and over again.

    No we don't.

    > I have been looking through a few hundred VM related bugzillas
    > and have found the same bugs persist over many different
    > versions of Linux, sometimes temporarily fixed, but they seem
    > to always come back eventually...
    >
    > > None of this is going anywhere, is is it?
    >
    > I will test my changes before I send them to you, but I cannot
    > promise you that you'll have the computers or software needed
    > to reproduce the problems. I doubt I'll have full time access
    > to such systems myself, either.
    >
    > 32GB is pretty much the minimum size to reproduce some of these
    > problems. Some workloads may need larger systems to easily trigger

    32GB isn't particularly large.

    Somehow I don't believe that a person or organisation which is incapable of
    preparing even a simple testcase will be capable of fixing problems such as
    this without breaking things.
    -
    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-03-03 00:09    [W:0.026 / U:0.268 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site