Messages in this thread | | | Date | Sun, 5 Oct 2008 17:30:19 -0700 | From | Arjan van de Ven <> | Subject | Re: [PATCH 2/3] Fix fsync livelock |
| |
On Sun, 5 Oct 2008 20:01:46 -0400 (EDT) Mikulas Patocka <mpatocka@redhat.com> wrote:
> I assume that if very few people complained about the livelock till > now, very few people will see degraded write performance. My patch > blocks the writes only if the livelock happens, so if the livelock > doesn't happen in unpatched kernel for most people, the patch won't > make it worse.
I object to calling this a livelock. It's not. And yes, fsync is slow and lots of people are seeing that. It's not helped by how ext3 is implemented (where fsync is effectively equivalent of a sync for many cases). But again, moving the latency to "innocent" parties is not acceptable.
> > > If the fsync() implementation isn't smart enough, sure, lets improve > > it. But not by shifting latency around... lets make it more > > efficient at submitting IO. > > If we need to invent something like "chained IO" where if you wait > > on the last of the chain, you wait on the entirely chain, so be it. > > This looks madly complicated. And ineffective, because if some page > was submitted before fsync() was invoked, and is under writeback > while fsync() is called, fsync() still has to wait on it.
so? just make a chain per inode always...
-- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
| |