Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp106879pxx; Tue, 27 Oct 2020 23:03:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4RbB/JMiHqF+IqKb5RBkKiTjuB7KfwYo7+LpxBZGHXHHnKBAjNekLr/9fUm828OU3WiMB X-Received: by 2002:a50:fb18:: with SMTP id d24mr6237978edq.43.1603865030725; Tue, 27 Oct 2020 23:03:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603865030; cv=none; d=google.com; s=arc-20160816; b=DgB6rgB1+DVJ3esn+SDVITGkN5N4aH/iNE4Yoa8jBuTxgtf7fOYcSIWt2m9/3fQqZy 4OD/KhX4lr2C955FTeWKMzUZKAw7ClI3Ag5yuB9JOeV8XVvzdQDzwVfSVOxD6gP70Jpm qK7GZsMou6J78V7SowtF3maY88REj4aXzIY2iYVxcAA+MtLEdJBuRtMz6PXmNINitkDY 9cKAeDOB5HT9HnCoOQc0hfZG9dZBjyiE6vWG4Q5VDVYIjjXF594Jy1ZeD3DTMZony+5r ppwizXHrdvOTkOXKmE+2GnAXFV3+sdjorhpd3OOK3AZGCxv30jdMrMQamHsyzkam8BIZ 4isw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=NfnTJiAmD6eL990WPNghr/NJ26oGL+XhgGB5yIi2I6Y=; b=RBy1qkboaERY3I3mRON5uQYcgpndfQh2jlMYPqgFORJYcyNLVdCu3eNPddZ6yAbJby E3+i9/7F1mvH8ou70hMZh8UQpNl65xRfqyyrtBxYpHlCqvQHrMRR4iimq3LILNDJslkI 42hwpnZJ0EYXBmzTdq72SmAWobLBoHupkHXvg2te2LYUGfw5D0rCC7LbXKCkwg3O3aUy fRbChCWYjBWs4UpGWSAJxD89m8zxedJIGfDKTeGdiE5HiL+HSVW3foJ+Hli+iilaPRqX 3OH/7SPBlPdKlpn742azu40+zK72BGbsBok1P3ESm1ko3d6i632QGd9DO1ZIfYUl8VaD hWCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="YaZ/ncPe"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h24si2758449ejf.680.2020.10.27.23.03.28; Tue, 27 Oct 2020 23:03:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="YaZ/ncPe"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2509587AbgJ0JHi (ORCPT + 99 others); Tue, 27 Oct 2020 05:07:38 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:58347 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2408749AbgJ0JHi (ORCPT ); Tue, 27 Oct 2020 05:07:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603789656; 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=NfnTJiAmD6eL990WPNghr/NJ26oGL+XhgGB5yIi2I6Y=; b=YaZ/ncPewqk4KCP4W6BpGL6XAjH2lPnOsr5SDn7pA2dC+2p6IrSMLISLfzXeJ2VVMtfUV2 v9+bpv3xbKe+TNMYw5VxbnGR+j56pQGU0N58omCByMzzMDcE0WewOoefQ41883xMsZuotu wCUdvMVQJHqgSBLVvfW3uVbTqEFvhKs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-20-74QlMOsKMKCNEHE_ukwAEg-1; Tue, 27 Oct 2020 05:07:32 -0400 X-MC-Unique: 74QlMOsKMKCNEHE_ukwAEg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 234BD186842C; Tue, 27 Oct 2020 09:07:31 +0000 (UTC) Received: from [10.36.113.185] (ovpn-113-185.ams2.redhat.com [10.36.113.185]) by smtp.corp.redhat.com (Postfix) with ESMTP id A31C12C31E; Tue, 27 Oct 2020 09:07:29 +0000 (UTC) Subject: Re: [PATCH 2/3] mm, page_poison: use static key more efficiently To: Vlastimil Babka , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Alexander Potapenko , Kees Cook , Michal Hocko , Mateusz Nosek References: <20201026173358.14704-1-vbabka@suse.cz> <20201026173358.14704-3-vbabka@suse.cz> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <4e35c52a-800a-4a60-2ef5-dd70a4f774c6@redhat.com> Date: Tue, 27 Oct 2020 10:07:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20201026173358.14704-3-vbabka@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26.10.20 18:33, Vlastimil Babka wrote: > Commit 11c9c7edae06 ("mm/page_poison.c: replace bool variable with static key") > changed page_poisoning_enabled() to a static key check. However, the function > is not inlined, so each check still involves a function call with overhead not > eliminated when page poisoning is disabled. > > Analogically to how debug_pagealloc is handled, this patch converts > page_poisoning_enabled() back to boolean check, and introduces > page_poisoning_enabled_static() for fast paths. Both functions are inlined. > > Also optimize the check that enables page poisoning instead of debug_pagealloc > for architectures without proper debug_pagealloc support. Move the check to > init_mem_debugging() to enable a single static key instead of having two > static branches in page_poisoning_enabled_static(). > > Signed-off-by: Vlastimil Babka [...] > +/* > + * For use in fast paths after init_mem_debugging() has run, or when a > + * false negative result is not harmful when called too early. > + */ > +static inline bool page_poisoning_enabled_static(void) > +{ > + return (static_branch_unlikely(&_page_poisoning_enabled)); return static_branch_unlikely(&_page_poisoning_enabled); > +} > #else > static inline bool page_poisoning_enabled(void) { return false; } > +static inline bool page_poisoning_enabled_static(void) { return false; } > static inline void kernel_poison_pages(struct page *page, int numpages, > int enable) { } > #endif > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b168c58ef337..2a1be197649d 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -777,6 +777,17 @@ void init_mem_debugging() > } > } > > +#ifdef CONFIG_PAGE_POISONING > + /* > + * Page poisoning is debug page alloc for some arches. If > + * either of those options are enabled, enable poisoning. > + */ > + if (page_poisoning_enabled() || > + (!IS_ENABLED(CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC) && > + debug_pagealloc_enabled())) Weird indentation if (page_poisoning_enabled() || (!IS_ENABLED(CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC) && debug_pagealloc_enabled())) > + static_branch_enable(&_page_poisoning_enabled); > +#endif > + > #ifdef CONFIG_DEBUG_PAGEALLOC > if (!debug_pagealloc_enabled()) > return; > @@ -2208,7 +2219,7 @@ static inline int check_new_page(struct page *page) > static inline bool free_pages_prezeroed(void) > { > return (IS_ENABLED(CONFIG_PAGE_POISONING_ZERO) && > - page_poisoning_enabled()) || want_init_on_free(); > + page_poisoning_enabled_static()) || want_init_on_free(); > } Apart from that LGTM. -- Thanks, David / dhildenb