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=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 80708C433F5 for ; Tue, 21 Sep 2021 15:04:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 28F9F610CA for ; Tue, 21 Sep 2021 15:04:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 28F9F610CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8A14594000D; Tue, 21 Sep 2021 11:04:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 851C5940007; Tue, 21 Sep 2021 11:04:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7417394000D; Tue, 21 Sep 2021 11:04:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 67B9B940007 for ; Tue, 21 Sep 2021 11:04:49 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2F147231D4 for ; Tue, 21 Sep 2021 15:04:49 +0000 (UTC) X-FDA: 78611902698.04.7C8BA98 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf08.hostedemail.com (Postfix) with ESMTP id CF8DA30000B4 for ; Tue, 21 Sep 2021 15:04:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632236688; 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: in-reply-to:in-reply-to:references:references; bh=2x5rqD0I1Z8EQgTGoic1TcC/yhS9DgiwB+H8dUYgCd0=; b=fED9KLFSWlgTTguwCEgel4ZnQq+SC/1L/DrQ85ttlumzYz5/OVhZNO7O0Rv62+LV/mv5Fy UllmA7ljGymQqE5AnCxaNOPzA99CC+cEdT2gGSrnOi92vdmVwA44DsN+Ln2fc/2fazjm7H YNi5/lMkhdFyw6JksWR95tqP0R/gIgI= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-339-RHE8BcWpPA6D3bddwcjKiw-1; Tue, 21 Sep 2021 11:04:45 -0400 X-MC-Unique: RHE8BcWpPA6D3bddwcjKiw-1 Received: by mail-qk1-f200.google.com with SMTP id e22-20020a05620a209600b003d5ff97bff7so179993762qka.1 for ; Tue, 21 Sep 2021 08:04:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2x5rqD0I1Z8EQgTGoic1TcC/yhS9DgiwB+H8dUYgCd0=; b=pES2VuvAV56GPfyituSvmRUk5t5DVT0DaXz5hwenxWotntZQOfzBb2KCI0D1SGo3Vk 10Ql1gGxpoyAjjc6czjY6Jc6sOEIIIPXLT6oxTLAyg/SDEBbC7eGhRTCWDqSJIUKys+j doWxdNuhsnz7QWxZU/WznlKu5+rUNHsD/ThFvgLci6fyl4+L0DUYXio6LiBG18SWLKia PS13NLczt9Au5hJJY3fKwtC/9G4BOgFbyHqYF+zHsq8ebAvYFnJ6bWsAt2IIHWHnc0mV N080ka7crT7liVMUeCv1+s5cS4yAMiT+8oianStv3YmAvF7ErDwZb3OO1Wgd/SoDAATT lOzQ== X-Gm-Message-State: AOAM530aKIV/bvsqyQKKtOGXBLoBmPDNyusSi+k6BEwGYuo/dNl4KAw5 9z6UIKF9nhDzeT6s4YkvY/TWNS000YcUl0OADf6bWYtI/r/c1DCvyWrbVXLrQZWuC6NIvtdfxy3 zx1F9K2uFFWU= X-Received: by 2002:a37:bfc6:: with SMTP id p189mr30693102qkf.33.1632236684766; Tue, 21 Sep 2021 08:04:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8U6vZ7gnxEMCR81lmgXlrbyrYpmkZLoTOiSc+Z8PManocp5D4HOKaV68dPRX4Kc12+vjS/g== X-Received: by 2002:a37:bfc6:: with SMTP id p189mr30693063qkf.33.1632236684470; Tue, 21 Sep 2021 08:04:44 -0700 (PDT) Received: from t490s ([2607:fea8:56a2:9100::d3ec]) by smtp.gmail.com with ESMTPSA id g17sm379283qkm.60.2021.09.21.08.04.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Sep 2021 08:04:43 -0700 (PDT) Date: Tue, 21 Sep 2021 11:04:42 -0400 From: Peter Xu To: Tiberiu Georgescu Cc: Andrew Morton , Jonathan Corbet , "david@redhat.com" , "linux-doc@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Ivan Teterevkov , Florian Schmidt , "Carl Waldspurger [C]" , Jonathan Davies Subject: Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions Message-ID: References: <20210920164931.175411-1-tiberiu.georgescu@nutanix.com> <20210920164931.175411-2-tiberiu.georgescu@nutanix.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CF8DA30000B4 X-Stat-Signature: j3p15i3qcab1bem4gn1efnch3a4t8835 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fED9KLFS; spf=none (imf08.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1632236688-393859 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: Hi, Tiberiu, On Tue, Sep 21, 2021 at 08:52:32AM +0000, Tiberiu Georgescu wrote: > I tested it some more, and it still looks like the mincore() syscall considers pages > in the swap cache as "in memory". This is how I tested: > > 1. Create a cgroup with 1M limit_in_bytes, and allow swapping > 2. mmap 1024 pages (both shared and private present the same behaviour) > 3. write to all pages in order > 4. compare mincore output with pagemap output > > This is an example of a usual mincore output in this scenario, shortened for > coherency (4x8 instead of 16x64): > 00000000 > 00000000 > 00001110 <- this bugs me > 01111111 > > The last 7 bits are definitely marking pages present in memory, but there are > some other bits set a little earlier. When comparing this output with the pagemap, > indeed, there are 7 consecutive pages present, and the rest of them are > swapped, including those 3 which are marked as present by mincore. > At this point, I can only assume the bits in between are on the swap cache. > > If you have another explanation, please share it with me. In the meanwhile, > I will rework the doc patch, and see if there is any other way to differentiate > clearly between the three types of pages. If not, I guess we'll stick to > mincore() and a best-effort 5th step. IIUC it could be because of that the pages are still in swap cache, so mincore() will return 1 for them too. What swap device are you using? I'm wildly guessing you're not using frontswap like zram. If that's the case, would you try zram? That should flush the page synchronously iiuc, then all the "suspecious 1s" will go away above. To do that, you may need to firstly turn off your current swap: # swapoff -a Then to configure zram you need: # modprobe zram # echo 4G > /sys/block/zram0/disksize # mkswap --label zram0 /dev/zram0 # swapon --priority 100 /dev/zram0 Quotting from here: https://wiki.archlinux.org/title/Improving_performance#zram_or_zswap Then you can try run the same test program again. Thanks, -- Peter Xu