lkml.org 
[lkml]   [2002]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [2.4.17/18pre] VM and swap - it's really unusable
    On Mon, Jan 14, 2002 at 06:03:43AM +0100, Daniel Phillips wrote:
    > On January 13, 2002 04:36 pm, Arjan van de Ven wrote:
    > > On Sun, Jan 13, 2002 at 04:18:29PM +0100, Roman Zippel wrote:
    > >
    > > > What somehow got lost in this discussion, that both patches don't
    > > > necessarily conflict with each other, they both attack the same problem
    > > > with different approaches, which complement each other. I prefer to get
    > > > the best of both patches.
    > >
    > > If you do this (and I've seen the results of doing both at once vs only
    > > either of then vs pure) then there's NO benifit for the preemption left.
    >
    > Sorry, that's incorrect. I stated why earlier in this thread and akpm signed
    > off on it. With preempt you get ASAP (i.e., as soon as the outermost
    > spinlock is done) process scheduling. With hand-coded scheduling points you
    > get 'as soon as it happens to hit a scheduling point'.
    >
    > That is not the only benefit, just the most obvious one.

    My understanding of this situation is as follows:
    The pure preempt measurements show some improvement on synthetic
    latency benchmarks that have not been shown to have any relationship
    to any real application

    The LL measurements show _better_ results on similar benchmarks.

    Some people find preempt improves "feel"
    Some people find LL improves "feel"

    The interactions of these improvements with Ingos scheduler, aa mm, and
    other recent patches are exceptionally murky

    We have one benchmark that shows that kernel compiles run on different
    untarred trees show a slight advantage for preempt+Ingo via some
    unknown mechanism. This benchmark, aside from its dubious repeatability
    tests something that seems to have no relationship to _anything_ at all
    by running a huge number of compile processes.

    Nobody has answered my question about the conflict between SMP per-cpu caching
    and preempt. Since NUMA is apparently the future of MP in the PC world and
    the future of Linux servers, it's interesting to consider this tradeoff.

    Nobody has answered the question about how to make sure all processes
    make progress with preempt.

    Nobody has offered a single benchmark of actual application code benefits
    from either preempt or LL.

    Nobody has clearly explained how to avoid what I claim to be the inevitable
    result of preempt -- priority inheritance locks (not just semaphores).
    What we have is some "we'll figure that out when we get to it".

    It's not even clear how preempt is supposed to interact with SCHED_FIFO.


    As far as your "most obvious" "benefit". It's neither obvious that it happens
    or obvious that it is a benefit. According to the measurements I've seen, Andrew
    reduces latency _more_ than preempt. Andrews argument, as I understand it, is that
    the longest latencies are within spinlocks anyways so increasing speed of preempt
    outside those locks misses the problem. If he is correct, then if you are correct,
    it doesn't matter - preempt is reducing already short latencies.

    BTW: there is a detailed explanation of how priority inherit works in Solaris in the
    UNIX Internals book. It's worth reading and thinking about.

    I'm not at all sure that putting preempt into 2.5 is a bad idea. I think that 2.4
    has a long lifetime ahead of it and the debacle that will follow putting preempt into 2.5
    will eventually discredit the entire idea for at least a year or two.
    But
    I think that there are some much more important scheduling issues that are being ignored to
    "improve the feel" of DVD playing. The key one is some idea of being able to assure processes
    of some rate of progress. This is not classical RT, but it is important to multimedia and
    databases and also to some applications we are interested in looking at.




    ---------------------------------------------------------
    Victor Yodaiken
    Finite State Machine Labs: The RTLinux Company.
    www.fsmlabs.com www.rtlinux.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: 2005-03-22 13:15    [W:3.862 / U:0.716 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site