Olaf Dietsche wrote:
>
> Andrew Morton <akpm@zip.com.au> writes:
>
> > http://www.huis.hiroshima-u.ac.jp/jargon/LexiconEntries/Livelock.html
> >
> > livelock
> >
> > /li:v'lok/ n. A situation in which some critical stage of a task is
> > unable to finish because its clients perpetually create more work
> > for it to do after they have been serviced but before it can clear its
> > queue. Differs from {deadlock} in that the process is not blocked or
> > waiting for anything, but has a virtually infinite amount of work to
> > do and can never catch up.
>
> I still don't get it :-(. When there is more work, this more work
> needs to be done. So, how could livelock be considered a bug? It's
> just overload. Or is this about the work, which must be done _after_
> the queue is empty?
>
Yes, it's just overload. Clearly, the CPU can dirty memory
faster than a disk can clean it.
The bug is the expectation in the design of sync() that
it'll ever be able to make all buffers clean.
We can either:
a) spin madly until the thing which is writing stuff stops.
This has some merit, but is of course racy.
b) give up when we see it's not working out or
c) acquire sufficient locking to prevent all new dirtyings,
while we proceed to flush everything to disk. This is
pointless, because as soon as we drop those locks, the
dirtyings start again.
The only reliable way we can do all this is to offline the device
while we flush everything. That happens on the unmount and
remount-ro path. We definitely need that to work.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:51 EST