Messages in this thread | | | From | Nick Piggin <> | Subject | Re: [PATCH] Memory management livelock | Date | Fri, 3 Oct 2008 22:27:50 +1000 |
| |
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 <nickpiggin@yahoo.com.au> wrote: > > > > 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?
| |