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=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 C5913C4727D for ; Fri, 25 Sep 2020 11:23:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E80E520936 for ; Fri, 25 Sep 2020 11:23:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E80E520936 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6A3CB8E0003; Fri, 25 Sep 2020 07:23:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6543E8E0001; Fri, 25 Sep 2020 07:23:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 591288E0003; Fri, 25 Sep 2020 07:23:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 443F78E0001 for ; Fri, 25 Sep 2020 07:23:54 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0B9038249980 for ; Fri, 25 Sep 2020 11:23:54 +0000 (UTC) X-FDA: 77301349188.24.day43_4911ce527167 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id DC6A91A4A0 for ; Fri, 25 Sep 2020 11:23:53 +0000 (UTC) X-HE-Tag: day43_4911ce527167 X-Filterd-Recvd-Size: 3072 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Sep 2020 11:23:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 06CBAADAB; Fri, 25 Sep 2020 11:23:49 +0000 (UTC) Subject: Re: [PATCH 9/9] mm, page_alloc: optionally disable pcplists during page isolation To: David Hildenbrand , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Michal Hocko , Pavel Tatashin , Oscar Salvador , Joonsoo Kim , Michal Hocko References: <20200922143712.12048-1-vbabka@suse.cz> <20200922143712.12048-10-vbabka@suse.cz> <10cdae53-c64b-e371-1b83-01d1af7a131e@redhat.com> From: Vlastimil Babka Message-ID: <2ce92f9a-eaa2-45b2-207c-46a79d6a2bde@suse.cz> Date: Fri, 25 Sep 2020 13:10:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 9/25/20 12:54 PM, David Hildenbrand wrote: >>> --- a/mm/page_isolation.c >>> +++ b/mm/page_isolation.c >>> @@ -15,6 +15,22 @@ >>> #define CREATE_TRACE_POINTS >>> #include >>> >>> +void zone_pcplist_disable(struct zone *zone) >>> +{ >>> + down_read(&pcp_batch_high_lock); >>> + if (atomic_inc_return(&zone->pcplist_disabled) == 1) { >>> + zone_update_pageset_high_and_batch(zone, 0, 1); >>> + __drain_all_pages(zone, true); >>> + } >> Hm, if one CPU is still inside the if-clause, the other one would >> continue, however pcp wpould not be disabled and zones not drained when >> returning. Ah, well spotted, thanks! >> (while we only allow a single Offline_pages() call, it will be different >> when we use the function in other context - especially, >> alloc_contig_range() for some users) >> >> Can't we use down_write() here? So it's serialized and everybody has to >> properly wait. (and we would not have to rely on an atomic_t) > Sorry, I meant down_write only temporarily in this code path. Not > keeping it locked in write when returning (I remember there is a way to > downgrade). Hmm that temporary write lock would still block new callers until previous finish with the downgraded-to-read lock. But I guess something like this would work: retry: if (atomic_read(...) == 0) { // zone_update... + drain atomic_inc(...); else if (atomic_inc_return == 1) // atomic_cmpxchg from 0 to 1; if that fails, goto retry Tricky, but races could only read to unnecessary duplicated updates + flushing but nothing worse? Or add another spinlock to cover this part instead of the temp write lock...