lkml.org 
[lkml]   [2008]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH -v5 2/2] Updating ctime and mtime at syncing
    2008/1/17, Miklos Szeredi <miklos@szeredi.hu>:
    > > > I'm not sure this auto-updating is really needed (POSIX doesn't
    > > > mandate it).
    > >
    > > Peter Shtaubach, author of the first solution for this bug,
    > > and Jacob Ostergaard, the reporter of this bug, insist the "auto-update"
    > > feature to be implemented.
    >
    > Can they state their reasons for the insistence?
    >
    > > 1) a base patch: update time just from fsync() and remove_vma()
    > > 2) update time on sync(2) as well
    > > 3) update time on MS_ASYNC as well
    >
    > Oh, and the four-liner I posted the other day will give you 1) + 2) +
    > even more at a small fraction of the complexity. And tacking on the
    > reprotect code will solve the MS_ASYNC issue just the same.
    >
    > I agree, that having the timestamp updated on sync() is nice, and that
    > trivial patch will give you that, and will also update the timestamp
    > at least each 30 seconds if the file is being constantly modified,
    > even if no explicit syncing is done.
    >
    > So maybe it's worth a little effort benchmarking how much that patch
    > affects the cost of writing to a page.
    >
    > You could write a little test program like this (if somebody hasn't
    > yet done so):
    >
    > - do some preparation:
    >
    > echo 80 > dirty_ratio
    > echo 80 > dirty_background_ratio
    > echo 30000 > dirty_expire_centisecs
    > sync
    >
    > - map a large file, one that fits comfortably into free memory
    > - bring the whole file in, by reading a byte from each page
    > - start the timer
    > - write a byte to each page
    > - stop the timer
    >
    > It would be most interesting to try this on a filesystem supporting
    > nanosecond timestamps. Anyone know which these are?

    The do_wp_page() function is called in mm/memory.c after locking PTE.
    And the file_update_time() routine calls the filesystem operation that can
    sleep. It's not accepted, I guess.

    >
    > Miklos
    > ----
    >
    > Index: linux/mm/memory.c
    > ===================================================================
    > --- linux.orig/mm/memory.c 2008-01-09 21:16:30.000000000 +0100
    > +++ linux/mm/memory.c 2008-01-15 21:16:14.000000000 +0100
    > @@ -1680,6 +1680,8 @@ gotten:
    > unlock:
    > pte_unmap_unlock(page_table, ptl);
    > if (dirty_page) {
    > + if (vma->vm_file)
    > + file_update_time(vma->vm_file);
    > /*
    > * Yes, Virginia, this is actually required to prevent a race
    > * with clear_page_dirty_for_io() from clearing the page dirty
    > @@ -2313,6 +2315,8 @@ out_unlocked:
    > if (anon)
    > page_cache_release(vmf.page);
    > else if (dirty_page) {
    > + if (vma->vm_file)
    > + file_update_time(vma->vm_file);
    > set_page_dirty_balance(dirty_page, page_mkwrite);
    > put_page(dirty_page);
    > }
    >
    >
    >


    \
     
     \ /
      Last update: 2008-01-17 17:23    [W:3.260 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site