Received: by 2002:ab2:788f:0:b0:1ee:8f2e:70ae with SMTP id b15csp427689lqi; Thu, 7 Mar 2024 01:08:09 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCU9PKp43fHCAVtL9e7I/sN4X6hJ4y6gQ/3egrD0FRC8SNfG1mAiQOXbLuXF/XL6h8/V+InXlPwZIcTr7RVY+VjAIlVazPKIOpdi3QvNWQ== X-Google-Smtp-Source: AGHT+IFklzZ5IZmiYbsBi3YPcooNgAPHwN9iYFu6WVnMb6arRttR82aZ3KFFQsDI1RM0b9zw1GVy X-Received: by 2002:a50:8e0b:0:b0:568:18df:ccce with SMTP id 11-20020a508e0b000000b0056818dfcccemr611880edw.40.1709802488967; Thu, 07 Mar 2024 01:08:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709802488; cv=pass; d=google.com; s=arc-20160816; b=Ke/etDgOotBdNYbjSJlpvyzoaFTkeGUqXmJ7WPdOzQVyAAxgvk+vV1xmmjsgJYputV X/TcLigN+Hyzs2u/8Ew5hrem4Bo7NvO84kQ8l1gtwhX+TMy4K055UdZrq8XIJBKGRlKx 8EbxKaTDV8us5f3MM6/bd84GRuIWbCZl0jIFQGYgz61LlQfIUzhOyAJvcZEwof/EkKq4 hteUJ15T+W9Sh4XZPgYWSYIInJkddFYWLYjaMI7qb1b3vxAC9p8boi8opWW9ZXof+jZo uFGVBsh99ONJBiZPMZyXGR9p2T4dcjh/MG8//v1AK/9zoSrMMRawULgcQzG9fOE93N1R UzvQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=7U6S0uMjoY5464xHIEpQ6A5eiW0P7LQ9cpiCqoLbS6A=; fh=Uv8oeMKk6BpYKH9vqptQH8TT5Eqxr2zgBor+qPOYKGQ=; b=GzNwSgguu/bbPj/eF24Jb0cu9XcLDZHj5Xy3hFAz7NaNdThEAskbYb4pLwXprLWsKZ QqWExSw7poZBmHqq+9c1m4NY1gM8IAWx8mxY+jglYtk9RbDHWUss6iyeX2PWFeUDgKBP eFcQRnbyjg+5HkiGQmZeNNbv1WvWu2Bv7xUer8eq0QK2lG4Bh/3eoeRFtKA1DJfkXb6y EyNTUfOUnt21xzRB+A1FXQXX0Z1KFhm0LbNm0LX0YBcVPf0e61PaeN9s/Kez7jG2MGZY 3PXIQqYdjMushMQbxY5MxiKyXcjsmIIoJVhlGZL0V1PZ47V0qed9ZyTGQFUxyhoxkER4 8h2g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-95184-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-95184-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id ds1-20020a0564021cc100b00566becd157csi6220189edb.662.2024.03.07.01.08.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 01:08:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-95184-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-95184-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-95184-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 3FD711F216CE for ; Thu, 7 Mar 2024 09:08:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9F26482D88; Thu, 7 Mar 2024 09:07:31 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 31AFA82D9A for ; Thu, 7 Mar 2024 09:07:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709802450; cv=none; b=RL9QDnlzNX2pzu2weQt/L4X5a435y3KxiOoxTXDMdZo2Vs1sO/To/ijslFVOOssa5MMyoz1+zOpq+ZSBYiJK6qM9H3TUgjk5XG7b4BEQXLyZPQ05ArLwytCNc8aDCKN8mMTZijA98xsFkqXyY/Q41/+WO39UolJ3D1ZdmuOKPMg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709802450; c=relaxed/simple; bh=AgkkfzG87LppxT5Q6LyQ+aMtDy/BNdQl+oPCFnZzVgs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rq756MCe3wjSnj1SEuMCfrI0vmIl6RVjSndjtOrhmQ4W1HCvrPFOXJ5r/CVacnBkWsPpd2acksvtyRz5+xxr6jK6ZbFLt1gEh6sWZ7Z8NScT8x3cCVzf+GifLjV8Kosh2jOF+rC0lxpYY643TA++BvfcuH+Gg8yCeSlhpBo+xtE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 4AFA11FB; Thu, 7 Mar 2024 01:08:04 -0800 (PST) Received: from [10.57.68.241] (unknown [10.57.68.241]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3BB813F762; Thu, 7 Mar 2024 01:07:24 -0800 (PST) Message-ID: <03458c20-5544-411b-9b8d-b4600a9b802f@arm.com> Date: Thu, 7 Mar 2024 09:07:22 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] mm/madvise: enhance lazyfreeing with mTHP in madvise_free Content-Language: en-GB To: Barry Song <21cnbao@gmail.com>, Lance Yang , david@redhat.com, Vishal Moola Cc: akpm@linux-foundation.org, zokeefe@google.com, shy828301@gmail.com, mhocko@suse.com, fengwei.yin@intel.com, xiehuan09@gmail.com, wangkefeng.wang@huawei.com, songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240307061425.21013-1-ioworker0@gmail.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07/03/2024 08:10, Barry Song wrote: > On Thu, Mar 7, 2024 at 9:00 PM Lance Yang wrote: >> >> Hey Barry, >> >> Thanks for taking time to review! >> >> On Thu, Mar 7, 2024 at 3:00 PM Barry Song <21cnbao@gmail.com> wrote: >>> >>> On Thu, Mar 7, 2024 at 7:15 PM Lance Yang wrote: >>>> >> [...] >>>> +static inline bool can_mark_large_folio_lazyfree(unsigned long addr, >>>> + struct folio *folio, pte_t *start_pte) >>>> +{ >>>> + int nr_pages = folio_nr_pages(folio); >>>> + fpb_t flags = FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRTY; >>>> + >>>> + for (int i = 0; i < nr_pages; i++) >>>> + if (page_mapcount(folio_page(folio, i)) != 1) >>>> + return false; >>> >>> we have moved to folio_estimated_sharers though it is not precise, so >>> we don't do >>> this check with lots of loops and depending on the subpage's mapcount. >> >> If we don't check the subpage’s mapcount, and there is a cow folio associated >> with this folio and the cow folio has smaller size than this folio, >> should we still >> mark this folio as lazyfree? > > I agree, this is true. However, we've somehow accepted the fact that > folio_likely_mapped_shared > can result in false negatives or false positives to balance the > overhead. So I really don't know :-) > > Maybe David and Vishal can give some comments here. > >> >>> BTW, do we need to rebase our work against David's changes[1]? >>> [1] https://lore.kernel.org/linux-mm/20240227201548.857831-1-david@redhat.com/ >> >> Yes, we should rebase our work against David’s changes. >> >>> >>>> + >>>> + return nr_pages == folio_pte_batch(folio, addr, start_pte, >>>> + ptep_get(start_pte), nr_pages, flags, NULL); >>>> +} >>>> + >>>> static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, >>>> unsigned long end, struct mm_walk *walk) >>>> >>>> @@ -676,11 +690,45 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, >>>> */ >>>> if (folio_test_large(folio)) { >>>> int err; >>>> + unsigned long next_addr, align; >>>> >>>> - if (folio_estimated_sharers(folio) != 1) >>>> - break; >>>> - if (!folio_trylock(folio)) >>>> - break; >>>> + if (folio_estimated_sharers(folio) != 1 || >>>> + !folio_trylock(folio)) >>>> + goto skip_large_folio; >>> >>> >>> I don't think we can skip all the PTEs for nr_pages, as some of them might be >>> pointing to other folios. >>> >>> for example, for a large folio with 16PTEs, you do MADV_DONTNEED(15-16), >>> and write the memory of PTE15 and PTE16, you get page faults, thus PTE15 >>> and PTE16 will point to two different small folios. We can only skip when we >>> are sure nr_pages == folio_pte_batch() is sure. >> >> Agreed. Thanks for pointing that out. >> >>> >>>> + >>>> + align = folio_nr_pages(folio) * PAGE_SIZE; >>>> + next_addr = ALIGN_DOWN(addr + align, align); >>>> + >>>> + /* >>>> + * If we mark only the subpages as lazyfree, or >>>> + * cannot mark the entire large folio as lazyfree, >>>> + * then just split it. >>>> + */ >>>> + if (next_addr > end || next_addr - addr != align || >>>> + !can_mark_large_folio_lazyfree(addr, folio, pte)) >>>> + goto split_large_folio; >>>> + >>>> + /* >>>> + * Avoid unnecessary folio splitting if the large >>>> + * folio is entirely within the given range. >>>> + */ >>>> + folio_clear_dirty(folio); >>>> + folio_unlock(folio); >>>> + for (; addr != next_addr; pte++, addr += PAGE_SIZE) { >>>> + ptent = ptep_get(pte); >>>> + if (pte_young(ptent) || pte_dirty(ptent)) { >>>> + ptent = ptep_get_and_clear_full( >>>> + mm, addr, pte, tlb->fullmm); >>>> + ptent = pte_mkold(ptent); >>>> + ptent = pte_mkclean(ptent); >>>> + set_pte_at(mm, addr, pte, ptent); >>>> + tlb_remove_tlb_entry(tlb, pte, addr); >>>> + } >>> >>> Can we do this in batches? for a CONT-PTE mapped large folio, you are unfolding >>> and folding again. It seems quite expensive. I'm not convinced we should be doing this in batches. We want the initial folio_pte_batch() to be as loose as possible regarding permissions so that we reduce our chances of splitting folios to the min. (e.g. ignore SW bits like soft dirty, etc). I think it might be possible that some PTEs are RO and other RW too (e.g. due to cow - although with the current cow impl, probably not. But its fragile to assume that). Anyway, if we do an initial batch that ignores all that then do this bit as a batch, you will end up smeering all the ptes with whatever properties were set on the first pte, which probably isn't right. I've done a similar conversion for madvise_cold_or_pageout_pte_range() as part of my swap-out series v4 (hoping to post imminently, but still working out a latent bug that it triggers). I use ptep_test_and_clear_young() in that, which arm64 can apply per-pte but avoid doing a contpte unfold/fold. I know you have to clear dirty here too, but I think this pattern is preferable. FYI, my swap-out series also halfway-batches madvise_free_pte_range() so that I can batch free_swap_and_cache() for the swap entry case. Ideally the work you are doing here would be rebased on top of that and plug-in to the approach implemented there. (subject to others' views of course). I'll cc you when I post it. >> >> Thanks for your suggestion. I'll do this in batches in v3. >> >> Thanks again for your time! >> >> Best, >> Lance >> >>> >>>> + } >>>> + folio_mark_lazyfree(folio); >>>> + goto next_folio; >>>> + >>>> +split_large_folio: >>>> folio_get(folio); >>>> arch_leave_lazy_mmu_mode(); >>>> pte_unmap_unlock(start_pte, ptl); >>>> @@ -688,13 +736,28 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, >>>> err = split_folio(folio); >>>> folio_unlock(folio); >>>> folio_put(folio); >>>> - if (err) >>>> - break; >>>> - start_pte = pte = >>>> - pte_offset_map_lock(mm, pmd, addr, &ptl); >>>> - if (!start_pte) >>>> - break; >>>> - arch_enter_lazy_mmu_mode(); >>>> + >>>> + /* >>>> + * If the large folio is locked or cannot be split, >>>> + * we just skip it. >>>> + */ >>>> + if (err) { >>>> +skip_large_folio: >>>> + if (next_addr >= end) >>>> + break; >>>> + pte += (next_addr - addr) / PAGE_SIZE; >>>> + addr = next_addr; >>>> + } >>>> + >>>> + if (!start_pte) { >>>> + start_pte = pte = pte_offset_map_lock( >>>> + mm, pmd, addr, &ptl); >>>> + if (!start_pte) >>>> + break; >>>> + arch_enter_lazy_mmu_mode(); >>>> + } >>>> + >>>> +next_folio: >>>> pte--; >>>> addr -= PAGE_SIZE; >>>> continue; >>>> -- >>>> 2.33.1 >>>> > > Thanks > Barry