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
    Andrea Arcangeli wrote:
    >
    > > --- linux-2.4.18-pre3/fs/buffer.c Fri Dec 21 11:19:14 2001
    > > +++ linux-akpm/fs/buffer.c Sat Jan 12 12:22:29 2002
    > > @@ -249,12 +249,19 @@ static int wait_for_buffers(kdev_t dev,
    > > struct buffer_head * next;
    > > int nr;
    > >
    > > - next = lru_list[index];
    > > nr = nr_buffers_type[index];
    > > +repeat:
    > > + next = lru_list[index];
    > > while (next && --nr >= 0) {
    > > struct buffer_head *bh = next;
    > > next = bh->b_next_free;
    > >
    > > + if (dev == NODEV && current->need_resched) {
    > > + spin_unlock(&lru_list_lock);
    > > + conditional_schedule();
    > > + spin_lock(&lru_list_lock);
    > > + goto repeat;
    > > + }
    > > if (!buffer_locke
    > > d(bh)) {
    >
    > this introduces possibility of looping indefinitely, this is why I
    > rejected it while I merged the mini-ll other points into -aa, if you
    > want to do anything like that at the very least you should roll the head
    > of the list as well or something like that.

    I ended up deciding that the `NODEV' check here avoids livelocks.
    Unless, of course, the scheduling pressure is so high that we can't
    even run a few statements. I which case the interrupt load will be so
    high that the machine stops anyway. Possibly it needs to check `refile'
    as well.

    A technique I frequently use in the full-ll patch is to only reschedule
    after we've executed the loop (say) 16 times before dropping out. This
    assures that forward progress is made. There's a test mode in the full
    ll patch - in this mode, it *always* assumes that need_resched is true.
    If the patch runs OK in this mode without livelocking, we know that it
    can't livelock.

    Anyway, I'll revisit this. It is a "must fix". wait_for_buffers() is
    possibly the worst cause of latency in the kernel. The usual scenario
    is where kupdate has written 10,000 buffers and then sleeps. Next time
    it wakes, it has 10,000 clean, unlocked buffers to move from BUF_LOCKED
    onto BUF_CLEAN. It does this with lru_list_lock held.

    -
    -
    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:4.359 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site