Messages in this thread | | | Date | Fri, 3 Oct 2008 07:43:46 -0400 (EDT) | From | Mikulas Patocka <> | Subject | Re: [PATCH] Memory management livelock |
| |
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
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).
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?
Mikulas
| |