From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB64DC43331 for ; Mon, 30 Mar 2020 18:41:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8FDF320714 for ; Mon, 30 Mar 2020 18:41:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FKSiivlF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FDF320714 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 41DA66B0032; Mon, 30 Mar 2020 14:41:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A78A6B0037; Mon, 30 Mar 2020 14:41:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 295DA6B006C; Mon, 30 Mar 2020 14:41:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id 0FBAD6B0032 for ; Mon, 30 Mar 2020 14:41:59 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B2AC6181AD0A5 for ; Mon, 30 Mar 2020 18:41:58 +0000 (UTC) X-FDA: 76652897916.19.lunch56_6889ea89f543f X-HE-Tag: lunch56_6889ea89f543f X-Filterd-Recvd-Size: 4935 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 30 Mar 2020 18:41:58 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id o1so3796149edv.1 for ; Mon, 30 Mar 2020 11:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=82V2uiPsUi/5h2Z1obVyGYc68C87qoYt95tk3QJZeQc=; b=FKSiivlFGGLxFugSuEF2WX8g4AFNohF4Go4nX5riJP4GbsCOoKGmNMm4OlgdyqzU7s qglZ7MRKIuIAF+SVGzkGuXJhfPzZfc0am3r0uedhhkA08rS09+ltmyVSZuZQtYOWz0BE mIBlIXE8f9y06jv1ClIkCFe/r/xKMJ4z5XrdDzLVsHgDciPhu8UxFJxoB8NqMAvOQ5a6 tBEzBdy+qM9TSdk7xhqhvz4ZJKTpc60TU2qyHR9CSAyqm+xgApdtzbT56CLg8Jg9Um8K YzUdgA4PhKnGaBbKTzl7raIJOo1Um6eGQskJ/er4RacA8ZPJdJePOEmlAN86CQrv9B3S APtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=82V2uiPsUi/5h2Z1obVyGYc68C87qoYt95tk3QJZeQc=; b=N1Ecvhgt99tzR2o6T8nUp+wy5uX2XCWbcPAoJWiRxSZFitJ632jRVIEKn7cvg9JUTm 0jU8eT4m6iFnacA9RnSITLNfr6g3K04kNy1IvegHOEFrkqaQf8UQs/m2KotuRXdX+Wq+ D7G8F/Jkqp2Z//EQPNN7tZ+xcDHa5C02RvngsQaVmZ9T+Xq4k9G8poh9JSa4FqV3hw3c N8Q9Hj+j4krmrYVuCN9YlVcqLU6gqChkYEF8cETQAsZEPycxYnaHrh8SfMXV8zab6+vu LlWzxlpq0AjdyNvs4g8qwbRMcdS07U5gpuXoycwd/E7tLAA9NEm17OsHh/rjckBq1/2N obuw== X-Gm-Message-State: ANhLgQ33/XhwuTDv90l0AEJSny6SaT+CNUAfPyqHBRL/aTp1HBBY3fp3 7eckzNnzKFnE5kzU3rVKC8hGT05altZ5UdQianw= X-Google-Smtp-Source: ADFU+vucxesQpx/pSt0ehsZzFwIuKyh+AB6mHBuwVgiT12sXj9/fSUvh1uUCw9ngYmsMM5saUV6HaYenqm4OhrNYV7E= X-Received: by 2002:aa7:d384:: with SMTP id x4mr6375157edq.256.1585593717445; Mon, 30 Mar 2020 11:41:57 -0700 (PDT) MIME-Version: 1.0 References: <20200327170601.18563-1-kirill.shutemov@linux.intel.com> <20200327170601.18563-6-kirill.shutemov@linux.intel.com> <20200328003920.xvkt3hp65uccsq7b@box> <20200328123336.givyrh5hsscg5cpx@box> In-Reply-To: <20200328123336.givyrh5hsscg5cpx@box> From: Yang Shi Date: Mon, 30 Mar 2020 11:41:44 -0700 Message-ID: Subject: Re: [PATCH 5/7] khugepaged: Allow to collapse PTE-mapped compound pages To: "Kirill A. Shutemov" Cc: Zi Yan , Andrew Morton , Andrea Arcangeli , Linux MM , Linux Kernel Mailing List , "Kirill A. Shutemov" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Mar 28, 2020 at 5:33 AM Kirill A. Shutemov wrote: > > On Fri, Mar 27, 2020 at 09:17:00PM -0400, Zi Yan wrote: > > > The compound page may be locked here if the function called for the first > > > time for the page and not locked after that (becouse we've unlocked it we > > > saw it the first time). The same with LRU. > > > > > > > For the first time, the compound page is locked and not on LRU, so this VM_BUG_ON passes. > > For the second time and so on, the compound page is unlocked and on the LRU, > > so this VM_BUG_ON still passes. > > > > For base page, VM_BUG_ON passes. > > > > Other unexpected situation (a compound page is locked and on LRU) triggers the VM_BU_ON, > > but your VM_BUG_ON will not detect this situation, right? > > Right. I will rework this code. I've just realized it is racy: after > unlock and putback on LRU the page can be locked by somebody else and this > code can unlock it which completely borken. I'm wondering if we shall skip putting the page back to LRU. Since the page is about to be freed soon, so as I mentioned in the other patch it sounds not very productive to put it back to LRU again. > > I'll pass down compound_pagelist to release_pte_pages() and handle the > situation there. > > > >>> if (likely(writable)) { > > >>> if (likely(referenced)) { > > >> > > >> Do we need a list here? There should be at most one compound page we will see here, right? > > > > > > Um? It's outside the pte loop. We get here once per PMD range. > > > > > > 'page' argument to trace_mm_collapse_huge_page_isolate() is misleading: > > > it's just the last page handled in the loop. > > > > > > > Throughout the pte loop, we should only see at most one compound page, right? > > No. mremap(2) opens a possibility for HPAGE_PMD_NR compound pages for > single PMD range. > > > -- > Kirill A. Shutemov >