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 9E57DC433F5 for ; Fri, 30 Sep 2022 09:40:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 396AB8D0002; Fri, 30 Sep 2022 05:40:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31ECC8D0001; Fri, 30 Sep 2022 05:40:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 198ED8D0002; Fri, 30 Sep 2022 05:40:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0361E8D0001 for ; Fri, 30 Sep 2022 05:40:25 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C4CCDC0B84 for ; Fri, 30 Sep 2022 09:40:24 +0000 (UTC) X-FDA: 79968256368.18.BB32723 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 57C55160009 for ; Fri, 30 Sep 2022 09:40:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664530823; 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=bOAQx+cKWm3EbsMD3IkvLXTlFRxCvE0EcUoclGvdQRk=; b=aH2LsnaR3bsSLolly9Ki4hiOfOcijb6lBvG+YJ8H0d8DodA24hqF/U4NwxcYj5z7cC6f5V QD8emJVjHzKstbnMZOruW6NplwpkIx3FDQTXcyaH7nvEPGEIxlWUiqcD80l1iqCnf8FSLR jHTXcdNQ0ObsJEMPtcChmz/Nim6ZMp0= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-669-7FttkHNROmy93TARfgKlTQ-1; Fri, 30 Sep 2022 05:40:21 -0400 X-MC-Unique: 7FttkHNROmy93TARfgKlTQ-1 Received: by mail-wr1-f69.google.com with SMTP id p7-20020adfba87000000b0022cc6f805b1so1374573wrg.21 for ; Fri, 30 Sep 2022 02:40:20 -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:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=bOAQx+cKWm3EbsMD3IkvLXTlFRxCvE0EcUoclGvdQRk=; b=cqtqlfObbQUa6QNSnB/6GjcKflznOdms7bXJ9OA7p4vI41F1iVgNxm6N3FUh3g4uYu aom2H3SuP1EwDH967hi6PHE9Y99fQ1Vi6aNx2ZqzTqweR6p8RQjBVM3CtS4fbD6BW5WN TM5dY9rfPk/gyM3vqXuANhEpOXZG8f5Vz9q6G4sGv2HNYV9gg/LfsDw4/dEbQDAUHsq9 fmn2UWRnwnbBLp4zxSQsTY+7c5BBAae67k0KzWyu8ycgzQJZ0n4NYhUGqs3mOQyt59LV id3xGCWuLmgxM+toBvz4Udps7g+nrvZiqZBr0nKzECKRG+VIQQaGWdAdhCftm9JBrq6N x8QA== X-Gm-Message-State: ACrzQf0jQcWOocpNlC3DJKL2LcKI4MIe4knu8S+RwMzsPQjFpPzGfiaT zIagQYmgkKB8eV9dEFElBjR/xlyCTBZHWxdO2AP2bUbxttRwrtHD7+Dthu93DSS16u/1vyNyAOp /h5OirH52Hg4= X-Received: by 2002:a05:6000:1f0c:b0:22c:c601:a824 with SMTP id bv12-20020a0560001f0c00b0022cc601a824mr5038488wrb.215.1664530819902; Fri, 30 Sep 2022 02:40:19 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4wSi36ADBqOfJFTbQ3pc2S/28fuP8wBvQBDe+GN6q1SBsyZPPoGxYPsjyMvmMHN12NSYfsHg== X-Received: by 2002:a05:6000:1f0c:b0:22c:c601:a824 with SMTP id bv12-20020a0560001f0c00b0022cc601a824mr5038469wrb.215.1664530819599; Fri, 30 Sep 2022 02:40:19 -0700 (PDT) Received: from ?IPV6:2003:cb:c70c:c00:48b:b68a:f9e0:ebce? (p200300cbc70c0c00048bb68af9e0ebce.dip0.t-ipconnect.de. [2003:cb:c70c:c00:48b:b68a:f9e0:ebce]) by smtp.gmail.com with ESMTPSA id m64-20020a1ca343000000b003a6125562e1sm1478481wme.46.2022.09.30.02.40.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Sep 2022 02:40:19 -0700 (PDT) Message-ID: <917e6889-2478-1992-6ef9-1b2ad450b02f@redhat.com> Date: Fri, 30 Sep 2022 11:40:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH 0/3] ksm: fix incorrect count of merged pages when enabling use_zero_pages To: Claudio Imbrenda Cc: xu.xin.sc@gmail.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xu xin References: <20220929025206.280970-1-xu.xin16@zte.com.cn> <4a3daba6-18f9-d252-697c-197f65578c44@redhat.com> <20220929123630.0951b199@p-imbrenda> <745f75a4-6a2a-630f-8228-0c5e081588e7@redhat.com> <20220929140548.1945dccf@p-imbrenda> <1fc6984b-bcc7-123d-1ea3-9e04d5b26529@redhat.com> <20220930113047.60800177@p-imbrenda> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220930113047.60800177@p-imbrenda> 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664530824; 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=bOAQx+cKWm3EbsMD3IkvLXTlFRxCvE0EcUoclGvdQRk=; b=juuF8rCgpnWq4UcvGdQ0yXZ+IjCAaUhxOFwF9yAH8Sl4Ob1HbCMmLM/HZz6fWWJlxu0NPj 8nyo+ICy7uUNEQ9syBLwJ21+ARqt2mIp+I5Rtsef5URsOpHhDC3BnkuckZlu8HTAKBFqaS w9poAgBz3I2qVSOBqSXQ7IPoU2uYXIQ= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aH2LsnaR; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664530824; a=rsa-sha256; cv=none; b=xmaBTdj8JiPDRRE0SiInqF2zlGjQPppioayWv4p6uuUbjO3X2sNCUCYWjpCjfxE/waG+su isXNbMeqctDEKtZqt7S07Gox7BLwiJZP1q+gz3+iJFhwxltgdv/wfZW2Oaro87y53zeLxu H9+anZoPXhPcBnVLEjdtgINIXu5Eqnk= X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 57C55160009 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aH2LsnaR; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: kf3j6idypb8xhofb1x89wh1bq8ehbq86 X-HE-Tag: 1664530824-166761 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: >>> >>>> >>>>> >>>>> second, once a page is merged with a zero page, it's not really handled >>>>> by KSM anymore. if you have a big allocation, of which you only touch a >>>>> few pages, would the rest be considered "merged"? no, it's just zero >>>>> pages, right? >>>> >>>> If you haven't touched memory, there is nothing populated -- no shared >>>> zeropage. >>>> >>>> We only populate shared zeropages in private anonymous mappings on read >>>> access without prior write. >>> >>> that's what I meant. if you read without writing, you get zero pages. >>> you don't consider those to be "shared" from a KSM point of view >>> >>> does it make a difference if some pages that have been written to but >>> now only contain zeroes are discarded and mapped back to the zero pages? >> >> That's a good question. When it comes to unmerging, you'd might expect >> that whatever was deduplicated will get duplicated again -- and your >> memory consumption will adjust accordingly. The stats might give an >> admin an idea regarding how much memory is actually overcommited. See >> below on the important case where we essentially never see the shared >> zeropage. >> >> The motivation behind these patches would be great -- what is the KSM >> user and what does it want to achieve with these numbers? > > anyone who works on big amounts of very sparse data, especially in a VM > (as I explained above, with KSM without use_zero_pages KVM guests lose > the zero page colouring) I meant the patches in question here :) > >> >>> >>>> >>>>> this is the same, except that we take present pages with zeroes in it >>>>> and we discard them and map them to zero pages. it's kinda like if we >>>>> had never touched them. >>>> >>>> MADV_UNMERGEABLE >>>> >>>> "Undo the effect of an earlier MADV_MERGEABLE operation on the >>>> specified address range; KSM unmerges whatever pages it had merged in >>>> the address range specified by addr and length." >>>> >>>> Now please explain to me how not undoing a zeropage merging is correct >>>> according to this documentation. >>>> >>> >>> because once it's discarded and replaced with a zero page, the page is >>> not handled by KSM anymore. >>> >>> I understand what you mean, that KSM did an action that now cannot be >>> undone, but how would you differentiate between zero pages that were >>> never written to and pages that had been written to and then discarded >>> and mapped back to a zero page because they only contained zeroes? >> >> An application that always properly initializes (write at least some >> part once) all its memory will never have the shared zeropage mapped. VM >> guest memory comes to mind, probably still the most important KSM use case. >> >> There are currently some remaining issues when taking a GUP R/O longterm >> pin on such a page (e.g., vfio). In contrast to KSM pages, such pins are >> not reliable for the shared zeropage, but I have fixes for them pending. >> However, that is rather a corner case (it didn't work at all correctly a >> while ago) and will be sorted out soon. >> >> So the question is if MADV_UNMERGEABLE etc. (stats) should be adjusted >> to document the behavior with use_zero_pages accordingly. > > we can count how many times a page full of zeroes was merged with a > zero-page, but we can't count how many time one of those pages was then > unmerged. once it's merged it becomes a zero-page, like the others. Right. We could special case on MADV_MERGEABLE ("how many zero pages do we have mapped into MADV_MERGEABLE VMAs"), but it gets tricky once we enable MADV_MERGEABLE on a region where the shared zeropage was already populated. Probably not worth the effort. -- Thanks, David / dhildenb