On Wed, 5 Sep 2007, Daniel Phillips wrote:
> If we remove our anti-deadlock measures, including the ddsnap.vm.fixes
> (a roll-up of Peter's patch set) and the request throttling code in
> dm-ddsnap.c, and apply your patch set instead, we hit deadlock on the
> socket write path after a few hours (traceback tomorrow). So your
> patch set by itself is a stability regression.
Na, that cannot be the case since it only activates when an OOM condition
would otherwise result.
> There is also some good news for you here. The combination of our
> throttling code, plus your recursive reclaim patches and some fiddling
> with PF_LESS_THROTTLE has so far survived testing without deadlocking.
> In other words, as far as we have tested it, your patch set can
> substitute for Peter's and produce the same effect, provided that we
> throttle the block IO traffic.
Ah. That is good news.
> It is clear which approach is more efficient: Peter's. This is because
> no scanning is required to pop a free page off a free list, so scanning
> work is not duplicated. How much more efficient is an open question.
> Hopefully we will measure that soon.
Efficiency is not a criterion for a rarely used emergency recovery
measure.
> Briefly touching on other factors:
>
> * Peter's patch set is much bigger than yours. The active ingredients
> need to be separated out from the other peterz bits such as reserve
> management APIs so we can make a fairer comparison.
Peters patch is much more invasive and requires a coupling of various
subsystems that is not good.
> * Your patch set here does not address the question of atomic
> allocation, though I see you have been busy with that elsewhere.
> Adding code to take care of this means you will start catching up
> with Peter in complexity.
Given your tests: It looks like we do not need it.
> * The questions Peter raised about how you will deal with loads
> involving heavy anonymous allocations are still open. This looks
> like more complexity on the way.
Either not necessary or also needed without these patches.
> * You depend on maintaining a global dirty page limit while Peter's
> approach does not. So we see the peterz approach as progress
> towards eliminating one of the great thorns in our side:
> congestion_wait deadlocks, which we currently hack around in a
> thoroughly disgusting way (PF_LESS_THROTTLE abuse).
We have a global dirty page limit already. I fully support Peters work on
dirty throttling.
These results show that Peters invasive approach is not needed. Reclaiming
easy reclaimable pages when necessary is sufficient.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
