lkml.org 
[lkml]   [2008]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-10-03 13:47    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site