lkml.org 
[lkml]   [2007]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] remove throttle_vm_writeout()
    On Fri, Oct 05, 2007 at 08:32:19PM +0200, Peter Zijlstra wrote:
    >
    > On Fri, 2007-10-05 at 13:50 -0400, Trond Myklebust wrote:
    > > On Fri, 2007-10-05 at 12:57 +0200, Peter Zijlstra wrote:
    > > > In this patch I totally ignored unstable, but I'm not sure that's the
    > > > proper thing to do, I'd need to figure out what happens to an unstable
    > > > page when passed into pageout() - or if its passed to pageout at all.
    > > >
    > > > If unstable pages would be passed to pageout(), and it would properly
    > > > convert them to writeback and clean them, then there is nothing wrong.
    > >
    > > Why would we want to do that? That would be a hell of a lot of work
    > > (locking pages, setting flags, unlocking pages, ...) for absolutely no
    > > reason.
    > >
    > > Unstable writes are writes which have been sent to the server, but which
    > > haven't been written to disk on the server. A single RPC command is then
    > > sent (COMMIT) which basically tells the server to call fsync(). After
    > > that is successful, we can free up the pages, but we do that with no
    > > extra manipulation of the pages themselves: no page locks, just removal
    > > from the NFS private radix tree, and freeing up of the NFS private
    > > structures.
    > >
    > > We only need to touch the pages again in the unlikely case that the
    > > COMMIT fails because the server has rebooted. In this case we have to
    > > resend the writes, and so the pages are marked as dirty, so we can go
    > > through the whole writepages() rigmarole again...
    > >
    > > So, no. I don't see sending pages through pageout() as being at all
    > > helpful.
    >
    > Well, the thing is, we throttle pageout in throttle_vm_writeout(). As it
    > stand we can deadlock there because it just waits for the numbers to
    > drop, and unstable pages don't automagically dissapear. Only
    > write_inodes() - normally called from balance_dirty_pages() will call
    > COMMIT.

    I wonder whether
    if (!bdi_nr_writeback)
    break;
    or something like that could avoid the deadlock?

    > So my thought was that calling pageout() on an unstable page would do
    > the COMMIT - we're low on memory, otherwise we would not be paging, so
    > getting rid of unstable pages seems to make sense to me.

    I guess "many unstable pages" would be better if we are taking this way.

    -
    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-10-06 02:43    [W:0.054 / U:0.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site