On Fri, 18 Aug 2006 16:44:01 -0700 Daniel Phillips <[email protected]> wrote: > handwaving - The mmap(MAP_SHARED)-the-whole-world scenario should be fixed by mm-tracking-shared-dirty-pages.patch. Please test it and if you are still able to demonstrate deadlocks, describe how, and why they are occurring. - We expect that the lots-of-dirty-anon-memory-over-swap-over-network scenario might still cause deadlocks. I assert that this can be solved by putting swap on local disks. Peter asserts that this isn't acceptable due to disk unreliability. I point out that local disk reliability can be increased via MD, all goes quiet. A good exposition which helps us to understand whether and why a significant proportion of the target user base still wishes to do swap-over-network would be useful. - Assuming that exposition is convincing, I would ask that you determine at what level of /proc/sys/vm/min_free_kbytes the swap-over-network deadlock is no longer demonstrable. If there are any remaining demonstrable deadlock scenarios, please describe how they were created and, if possible, perform some analysis of them for us. sysrq-T and sysrq-M traces would be helpful. Once we have this information in hand, we will be in a better position to work out how to solve these problems. Thanks. - 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/
- Follow-Ups:
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: "Philip R. Auld" <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: "Ray Lee" <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Rik van Riel <[email protected]>
- Re: Network receive stall avoidance (was [PATCH 2/9] deadlock prevention core)
- From: Daniel Phillips <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- References:
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Thomas Graf <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Rik van Riel <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Daniel Phillips <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: David Miller <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Daniel Phillips <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Andrew Morton <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Peter Zijlstra <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Andrew Morton <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Daniel Phillips <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Andrew Morton <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Daniel Phillips <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Andrew Morton <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Daniel Phillips <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Andrew Morton <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- From: Daniel Phillips <[email protected]>
- Re: [RFC][PATCH 2/9] deadlock prevention core
- Prev by Date: Re: [ckrm-tech] [RFC][PATCH 2/7] UBC: core (structures, API)
- Next by Date: Re: [ckrm-tech] [RFC][PATCH 4/7] UBC: syscalls (user interface)
- Previous by thread: Re: [RFC][PATCH 2/9] deadlock prevention core
- Next by thread: Re: Network receive stall avoidance (was [PATCH 2/9] deadlock prevention core)
- Index(es):