[lkml]   [2008]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Memory management livelock
    On Friday 03 October 2008 21:43, Mikulas Patocka wrote:
    > On Thu, 2 Oct 2008, Andrew Morton wrote:
    > > On Fri, 3 Oct 2008 13:47:21 +1000 Nick Piggin <>
    > > > > I expect there's no solution which avoids blocking the writers at
    > > > > some stage.
    > > >
    > > > See my other email. Something roughly like this would do the trick
    > > > (hey, it actually boots and runs and does fix the problem too).
    > >
    > > It needs exclusion to protect all those temp tags. Is do_fsync()'s
    > > i_mutex sufficient? It's qute unobvious (and unmaintainable?) that all
    > > the callers of this stuff are running under that lock.
    > That filemap_fdatawrite and filemap_fdatawait in fsync() aren't really
    > called under i_mutex (see do_fsync).
    > So the possible solutions are:
    > 1. Add jiffies when the page was diried and wroteback to struct page
    > + no impact on locking and concurrency
    > - increases the structure by 8 bytes

    This one is not practical.

    > 2. Stop the writers when the starvation happens (what I did)
    > + doesn't do any locking if the livelock doesn't happen
    > - locks writers when the livelock happens (I think it's not really serious
    > --- because very few people complained about the livelock, very few people
    > will see performance degradation from blocking the writers).

    Maybe it is because not much actually does sequential writes to a massive
    file or block device while trying to fsync it as well? I don't know. You
    could still have cases where fsync takes much longer than expected but it
    is still not long enough for a user to report it as a "livelock" bug.

    > 3. Add another bit to radix tree (what Nick did)
    > + doesn't ever block writers
    > - unconditionally takes the lock on fsync path and serializates concurrent
    > syncs/fsyncs. Probably low overhead too ... or I don't know, is there any
    > possible situation when more processes execute sync() in parallel and user
    > would see degradations if those syncs were serialized?

     \ /
      Last update: 2008-10-03 14:31    [W:0.022 / U:0.076 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site