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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36A9AC4332F for ; Thu, 6 Oct 2022 09:20:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54ACE6B0071; Thu, 6 Oct 2022 05:20:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FB0B8E0002; Thu, 6 Oct 2022 05:20:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39B528E0001; Thu, 6 Oct 2022 05:20:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 286766B0071 for ; Thu, 6 Oct 2022 05:20:50 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E05E880E62 for ; Thu, 6 Oct 2022 09:20:49 +0000 (UTC) X-FDA: 79989979818.22.6BEF6A1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 58B03C001B for ; Thu, 6 Oct 2022 09:20:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665048048; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mw6vh8Fj2nr/tAp1jCRdKpprVY4vooB4N4OGmMaId3w=; b=YuuUUfcc5bZKpIjSHY/F/RUMsUTuZjX/+Rp32Irnfoo3sJzNzO1K3xhpgCMVXmF4EwvMHA 4Wi/sBVaHT4ChrBGCU8Z6DiEUQn70vQax2kZ2QJIWL2S9CfFJ7l5zl49/97QyVLV8VVNM/ oa8RXacDDNY9XJWCCqi7h+cXljM2cw4= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-608-sbHVTuiAOYyIEv4JtaObNw-1; Thu, 06 Oct 2022 05:20:45 -0400 X-MC-Unique: sbHVTuiAOYyIEv4JtaObNw-1 Received: by mail-wr1-f70.google.com with SMTP id e19-20020adfa453000000b0022e3608df56so297120wra.10 for ; Thu, 06 Oct 2022 02:20:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=mw6vh8Fj2nr/tAp1jCRdKpprVY4vooB4N4OGmMaId3w=; b=q6/hmogynbhgPV2ohNwD04X+Pxd0bUB/DVQX+s3+8vGXsfX41S5qXNrMgwlOTjaU+T /LJJifZOObgXP8u5voJ3yV0o5pmT3Bv0PST20F7bg3maa8oVb5CML+ZeUo0NlqN/X+kw L/XPWFbIaO0duvu/LfMBFb+42YHeqiSDCUTktlMAs0OW6KeaJomUYl2cQrqH5aR6LM/A rKt7p3bu5dknMtq8eg8D5KdgfZhQIPMBzbt0+arz68VPXbc6TouIsRgWeYxd0bYwdsPh fYF7CfU0wASXnLrzRCQFfQjODXxEJIDCqOkq31s2ijSEm+BV2Gbp4f/yP0ytOklmkY6v u1EQ== X-Gm-Message-State: ACrzQf0GWgxrmraZz2FjHsOiTHQuNZ+LZOeYmnpRZ2YY4aKRh55gj9iV GShOMqt1XSXNLmPMiX5C2MhvfWT5pXoY3iBtvaClnvebWul2w2GeAXhBy7Dl30bIM2TRWlmDLEr zNmMLTxFLcZI= X-Received: by 2002:a05:6000:783:b0:22e:35dd:5f48 with SMTP id bu3-20020a056000078300b0022e35dd5f48mr2418053wrb.106.1665048044465; Thu, 06 Oct 2022 02:20:44 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6CPRIjlEs2RQKZxShqi1C0hC1GtJGCC/hdDMM0onx6qferHIFo+jEb+L9bsJrIDf7AP0JKGg== X-Received: by 2002:a05:6000:783:b0:22e:35dd:5f48 with SMTP id bu3-20020a056000078300b0022e35dd5f48mr2418025wrb.106.1665048044084; Thu, 06 Oct 2022 02:20:44 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:3700:aed2:a0f8:c270:7f30? (p200300cbc7053700aed2a0f8c2707f30.dip0.t-ipconnect.de. [2003:cb:c705:3700:aed2:a0f8:c270:7f30]) by smtp.gmail.com with ESMTPSA id az30-20020adfe19e000000b002286670bafasm7091697wrb.48.2022.10.06.02.20.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Oct 2022 02:20:43 -0700 (PDT) Message-ID: <9a84440f-1462-2193-7dd6-c84e8bb22232@redhat.com> Date: Thu, 6 Oct 2022 11:20:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Andrew Morton , Shuah Khan , Hugh Dickins , Vlastimil Babka , Andrea Arcangeli , "Matthew Wilcox (Oracle)" , Jason Gunthorpe , John Hubbard References: <20220930141931.174362-1-david@redhat.com> <20220930141931.174362-7-david@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1 6/7] mm/ksm: convert break_ksm() to use walk_page_range_vma() In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665048049; a=rsa-sha256; cv=none; b=8AelnZfIj0IaYhlD+Fz2FX+FgIon7vJuoeLzohlhcj52tsbYVHR9SAs58no666h+AYQnxa enzG9CFZBrJTDqLRBItJxMrPZpEirmF2yKCUcgvR02blpa7D2I5k84dRIaHPGDPDVUU2zY pfphWVhBMKYmPSMnXjfv83IdSsUdqsU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YuuUUfcc; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665048049; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mw6vh8Fj2nr/tAp1jCRdKpprVY4vooB4N4OGmMaId3w=; b=d4eB2PJJ9dnM7ccOXSgYHuw8nh3qmeOpM/9mxjhmjPdM4vqVTFuD6s2ApQpj0XVymDWFNm gR4fCPGh5IdxbXKcsQtyndngdeVXXQ5fo+lkgUJfx18YCz7K4zk5DV/gBPdxqLlaVvhqos kXEMO85CEqZ78x7mmrA2Ubm6GDtVRPg= X-Rspamd-Queue-Id: 58B03C001B X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YuuUUfcc; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: icu5n7drtdakgcf17dxwz93wjcwtzi7r X-Rspamd-Server: rspam04 X-HE-Tag: 1665048049-620105 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: >> +int break_ksm_pud_entry(pud_t *pud, unsigned long addr, unsigned long next, >> + struct mm_walk *walk) >> +{ >> + /* We only care about page tables to walk to a single base page. */ >> + if (pud_leaf(*pud) || !pud_present(*pud)) >> + return 1; >> + return 0; >> +} > > Is this needed? I thought the pgtable walker handlers this already. > > [...] > Most probably yes. I was trying to avoid about PUD splits, but I guess we simply should not care in VMAs that are considered by KSM (MERGABLE). Most probably never ever happens. >> static int break_ksm(struct vm_area_struct *vma, unsigned long addr) >> { >> - struct page *page; >> vm_fault_t ret = 0; >> >> + if (WARN_ON_ONCE(!IS_ALIGNED(addr, PAGE_SIZE))) >> + return -EINVAL; >> + >> do { >> bool ksm_page = false; >> >> cond_resched(); >> - page = follow_page(vma, addr, >> - FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE); >> - if (IS_ERR_OR_NULL(page)) >> - break; >> - if (PageKsm(page)) >> - ksm_page = true; >> - put_page(page); >> + ret = walk_page_range_vma(vma, addr, addr + PAGE_SIZE, >> + &break_ksm_ops, &ksm_page); >> + if (WARN_ON_ONCE(ret < 0)) >> + return ret; > > I'm not sure this would be worth it, especially with a 4% degrade. The > next patch will be able to bring 50- LOC, but this patch does 60+ anyway, > based on another new helper just introduced... > > I just don't see whether there's strong enough reason to do so to drop > FOLL_MIGRATE. It's different to the previous VM_FAULT_WRITE refactor > because of the unshare approach was much of a good reasoning to me. > > Perhaps I missed something? My main motivation is to remove most of that GUP hackery here, which is 1) Getting a reference on a page and waiting for migration to finish even though both is unnecessary. 2) As we don't have sufficient control, we added FOLL_MIGRATION hacks to MM core to work around limitations in the GUP-based approacj. 3) We rely on legacy follow_page() interface that we should really get rid of in the long term. All we want to do is walk the page tables and make a decision if something we care about is mapped. Instead of leaking these details via hacks into GUP code and making that code harder to grasp/maintain, this patch moves that logic to the actual user, while reusing generic page walking code. Yes, we have to extend page walking code, but it's just the natural, non-hacky way of doing it. Regarding the 4% performance degradation (if I wouldn't have added the benchmarks, nobody would know and probably care ;) ), I am not quite sure why that is the case. We're just walking page tables after all in both cases. Maybe the callback-based implementation of pagewalk code is less efficient, but we might be able to improve that implementation if we really care about performance here. Maybe removing break_ksm_pud_entry() already improves the numbers slightly. Thanks! -- Thanks, David / dhildenb