Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3268099pxj; Mon, 24 May 2021 02:43:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxM7+vdt+JurQ3sCWxFBqnI5LjLlAPitDIGc1l+UpQIpL4v3BIjBYKkdY4tEw1aDoG4zv0F X-Received: by 2002:aa7:c7cc:: with SMTP id o12mr25172950eds.291.1621849387754; Mon, 24 May 2021 02:43:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621849387; cv=none; d=google.com; s=arc-20160816; b=tIITERsb8QP0fniUQY8R/o7SXIkSgcOrTmsVGVhHARRa9ABGbZBwiD7sg590vN2hvk UJWOZH/FVwQjlflhtBs1n6kK6CnmFn4EBqtV1XxsohT1AlraFb1+Lvi98EqQK5bGcQc3 drK3iMvzML4VZp+2E0zoTpXghk6P7EU78nNMCv9MwH7mRhpPVfArZpUger6OpWvrioie /TfKZZdZ88N4c09bCDUAFGcQCtLqBE0I/V2ekfWsh8+ak9fPjWHgyv6+4FiyGfHRfLVh ZFZXIHnRtto+P77UYcZI8Qvn8Pvqb+3bJgAh65jg+F/svkLiHIxN3TCMWHI+Fqw52nk3 5rJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=32o4TLhfcjpkOjwgdP2Kmkkn/FIistH7OiQfil70SXQ=; b=CmyMVEfD8+FPN6WHCVBniUbQadClhkDH+Ruzn2utSX97y3pdMFl3099RRkUx31yuEa jqZSmzIjLXqPge1VAx/bVwGgbpf+H+O1/Fpn7D12tJ2avAiiQjWpN4dLdc0zGaNbL2dJ swYaLv95lnONjtToxvc8B8KK3Wh6fPAt/BIbbO2Pa2g3olJDsbCpf7KrHeFx4kzcgT7i M5X7Quw+qXpyFJmFYT6JWPlWc+kOk/EQJdHjYpbi6Mug4+1oq4I+WMJNpgE69G+oIO+R EuWg99pVI9C/W1Kk7KV/kOB1byvQJiDRldKdN1CDe0Y3Q2Q2xyYb6ckiU19VlmCeqXKQ rGhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id co1si12256515edb.166.2021.05.24.02.42.45; Mon, 24 May 2021 02:43:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232445AbhEXJmP (ORCPT + 99 others); Mon, 24 May 2021 05:42:15 -0400 Received: from foss.arm.com ([217.140.110.172]:40330 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232313AbhEXJmO (ORCPT ); Mon, 24 May 2021 05:42:14 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DED0F31B; Mon, 24 May 2021 02:40:46 -0700 (PDT) Received: from [10.163.81.166] (unknown [10.163.81.166]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7B64F3F73B; Mon, 24 May 2021 02:40:43 -0700 (PDT) Subject: Re: [PATCH] mm/thp: Make ARCH_ENABLE_SPLIT_PMD_PTLOCK dependent on PGTABLE_LEVELS > 2 To: Gerald Schaefer Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Heiko Carstens , Vasily Gorbik , Thomas Gleixner , Ingo Molnar , x86@kernel.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org References: <1620621345-29176-1-git-send-email-anshuman.khandual@arm.com> <20210517161358.49683f34@thinkpad> <20210519130722.7d255b7f@thinkpad> From: Anshuman Khandual Message-ID: <06299fb2-2f64-9094-3bf4-77045101ae22@arm.com> Date: Mon, 24 May 2021 15:11:27 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210519130722.7d255b7f@thinkpad> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/19/21 4:37 PM, Gerald Schaefer wrote: > On Mon, 17 May 2021 16:13:57 +0200 > Gerald Schaefer wrote: > >> On Mon, 17 May 2021 09:45:31 +0530 >> Anshuman Khandual wrote: >> >>> >>> >>> On 5/10/21 10:05 AM, Anshuman Khandual wrote: >>>> ARCH_ENABLE_SPLIT_PMD_PTLOCK is irrelevant unless there are two page table >>>> levels including PMD (also per Documentation/vm/split_page_table_lock.rst). >>>> Make this dependency explicit on remaining platforms i.e x86 and s390 where >>>> ARCH_ENABLE_SPLIT_PMD_PTLOCK is subscribed. >> >> For s390, I don't think this makes a lot of sense. We always have 5 levels >> defined for PGTABLE_LEVELS, and we would not even compile with any other >> value, because of the "#error CONFIG_PGTABLE_LEVELS" in include/linux/pgtable.h. >> >> Our pagetable folding also works a bit different than it does on other archs, >> and we would actually have pmd level entries for 2-level pagetables, so it should >> all work fine also with PGTABLE_LEVELS == 2 (if it was possible). >> >> In fact, I do not really see why you would need "more than two levels" on any >> arch, in order to use split PMD locks. Your description also just says >> "irrelevant unless there are two page table levels", and not "more than two >> levels", like in Documentation/vm/split_page_table_lock.rst. >> >> Yet, your patch adds checks for "more than", so at least the description >> seems a bit misleading. I assume that the "more than" has to do with folded >> PMD on a 2-level system, but the way we fold on s390 I do not see why that >> should be a problem. Could you please elaborate a bit? >> >> We also have different levels of pagetables for kernel (CONFIG_PGTABLE_LEVELS) >> and user processes on s390. The latter can have dynamic levels, currently >> starting with 3, but previously we also had 2 levels for compat tasks e.g. >> These dynamic levels for user processes are also independent from the >> CONFIG_PGTABLE_LEVELS used for the kernel pagetable, while the split PMD lock >> of course also affects user process pagetables, so that would be another >> reason not to add such a dependency for ARCH_ENABLE_SPLIT_PMD_PTLOCK on s390. > > Ouch, I guess I was a bit confused here. I thought the split PMD lock > was part of the struct page for the 4 KB page where the PMD entry is located, > and therefore, with more than one page, it still would make (a little) sense > to use it also for 2 pagetable levels. > > However, pmd_to_page() always returns the struct page of the first page, > so there is only one split PMD lock for the whole thing (4 pages for s390). > Of course that means that with 2 pagetable levels, and only one PMD directory, > the split PMD lock would be equivalent to the global pagetable lock, and > therefore not make any sense. > > Maybe you could change the description to also mention "more than two" > levels? Yes, will change it. > > I still do not see a real benefit of the patch, e.g. it does not really > fix any possible misconfiguration, at least on s390. But it certainly is not > wrong, and at least it had the benefit of making me aware again of how split > PMD locks work, so I'll happily add this Right, even though it does not change the functionality, the purpose of this patch is to enforce (and also possibly document) an inherent assumption which may not hold true on all other platforms like arm64. > > Acked-by: Gerald Schaefer # s390 > Thanks for reviewing.