From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e28smtp01.in.ibm.com (e28smtp01.in.ibm.com [125.16.236.1]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 708F91A19DA for ; Mon, 11 Jan 2016 17:31:39 +1100 (AEDT) Received: from localhost by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 11 Jan 2016 12:01:35 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 80250E005E for ; Mon, 11 Jan 2016 12:02:50 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0B6VW1T53739724 for ; Mon, 11 Jan 2016 12:01:32 +0530 Received: from d28av01.in.ibm.com (localhost [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0B6VRO7020346 for ; Mon, 11 Jan 2016 12:01:31 +0530 From: "Aneesh Kumar K.V" To: Hugh Dickins Cc: Hugh Dickins , Laurent Dufour , Andrew Morton , Michael Ellerman , Cyrill Gorcunov , Martin Schwidefsky , linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org Subject: Re: [PATCH next] powerpc/mm: fix _PAGE_SWP_SOFT_DIRTY breaking swapoff In-Reply-To: References: <87mvscu0ve.fsf@linux.vnet.ibm.com> Date: Mon, 11 Jan 2016 12:01:19 +0530 Message-ID: <87h9iktyo8.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hugh Dickins writes: > On Mon, 11 Jan 2016, Aneesh Kumar K.V wrote: >> Hugh Dickins writes: >> >> > Swapoff after swapping hangs on the G5, when CONFIG_CHECKPOINT_RESTORE=y >> > but CONFIG_MEM_SOFT_DIRTY is not set. That's because the non-zero >> > _PAGE_SWP_SOFT_DIRTY bit, added by CONFIG_HAVE_ARCH_SOFT_DIRTY=y, is not >> > discounted when CONFIG_MEM_SOFT_DIRTY is not set: so swap ptes cannot be >> > recognized. >> > >> > (I suspect that the peculiar dependence of HAVE_ARCH_SOFT_DIRTY on >> > CHECKPOINT_RESTORE in arch/powerpc/Kconfig comes from an incomplete >> > attempt to solve this problem.) >> > >> > It's true that the relationship between CONFIG_HAVE_ARCH_SOFT_DIRTY and >> > and CONFIG_MEM_SOFT_DIRTY is too confusing, and it's true that swapoff >> > should be made more robust; but nevertheless, fix up the powerpc ifdefs >> > as x86_64 and s390 (which met the same problem) have them, defining the >> > bits as 0 if CONFIG_MEM_SOFT_DIRTY is not set. >> >> Do we need this patch, if we make the maybe_same_pte() more robust. The >> #ifdef with pte bits is always a confusing one and IMHO, we should avoid >> that if we can ? > > If maybe_same_pte() were more robust (as in the pte_same_as_swp() patch), > this patch here becomes an optimization rather than a correctness patch: > without this patch here, pte_same_as_swp() will perform an unnecessary > transformation (masking out _PAGE_SWP_SOFT_DIRTY) from every one of the > millions of ptes it has to examine, on configs where it couldn't be set. > Or perhaps the processor gets that all nicely lined up without any actual > delay, I don't know. But we have #ifndef CONFIG_HAVE_ARCH_SOFT_DIRTY static inline pte_t pte_swp_clear_soft_dirty(pte_t pte) { return pte; } #endif If we fix the CONFIG_HAVE_ARCH_SOFT_DIRTY correctly, we can do the same optmization without the #ifdef of pte bits right ? > > I've already agreed that the way SOFT_DIRTY is currently config'ed is > too confusing; but until that's improved, I strongly recommend that you > follow the same way of handling this as x86_64 and s390 are doing - going > off and doing it differently is liable to lead to error, as we have seen. > > So I recommend using the patch below too, whether or not you care for > the optimization. > > Hugh -aneesh