Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp55046imm; Tue, 24 Jul 2018 13:55:02 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcUX/ercMVZzZz3mqQvw71Ll4G5QJGRGO9MvhAo2eDZtwuLQ8Dj32XnaASjCjP7KVbYVaBy X-Received: by 2002:a62:591a:: with SMTP id n26-v6mr19249540pfb.94.1532465701990; Tue, 24 Jul 2018 13:55:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532465701; cv=none; d=google.com; s=arc-20160816; b=TdHkg4pwX8tct9DGqonwTKRH7iavFhqBblbJdartmpZ/vFWdUavh9lGbwxx6lpKIVu XQySh5sDJcTuI8volhzp9FRTxDdYiIc0n40c2DU6tMblAGhtamc1u4zypfbQ6LqYHhwh wMwy3nr0VNA93ct6Zly7WrjgAhXuSkP9uyuEMp4D04tlnI1yTHcP9Lwo5vQede4PzBZ3 wxu+vml6F1l7sjVY8IFbvOBP/gUWVs+MLctSBNMeoU82hlcwzTFKxtcUwdar0Txjm5Lk OGlh6X6peUQuW7iwuPaLjNQpOw7e70q4kzNjf9+LnHFSFb2B/HIQtUqr/G3qIokWyzBL qZMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=kKM6r/0IHcl5+S7d6WN+FbGZPnaQRuKQPUpAt04vKyc=; b=L6+b5Cv9vfImR6HNhgAnnD+b07TqKVHPrQfltAUQKwNOSUIz7gJcJ2YX/WA6kNoMeE JeJB0aBAOPPWbSyKj4n2OJb5/chiwDxqpEyLU2orKcISpH6xT7hoUmf9pjvsbygMYVrn lKpdPpBs9QAUVuvbg7ub2iM7KsWewt5ErFOPbQBdruVZok+ufSo0IYYIuSih4ahKxbIR 8axmY7uuuPERDoPrLFCYJf8svryTzqqVKx/6z12IL71tR3JSwcJGbnFjydODUkhgtx+Y WpGAP55qlqurL7bDJ2J5maSR0OQi2t25gYj/0NzEr9aHiXTjmAkp3aN7n09NVSwY39A5 HSNg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j6-v6si12673848pgn.416.2018.07.24.13.54.47; Tue, 24 Jul 2018 13:55:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388847AbeGXWCI (ORCPT + 99 others); Tue, 24 Jul 2018 18:02:08 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:34346 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388651AbeGXWCI (ORCPT ); Tue, 24 Jul 2018 18:02:08 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 4A940D9D; Tue, 24 Jul 2018 20:53:51 +0000 (UTC) Date: Tue, 24 Jul 2018 13:53:50 -0700 From: Andrew Morton To: Cannon Matthews Cc: Michal Hocko , Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andres Lagar-Cavilla , Salman Qazi , Paul Turner , David Matlack , Peter Feiner , Alain Trinh Subject: Re: [PATCH] RFC: clear 1G pages with streaming stores on x86 Message-Id: <20180724135350.91a90f4f8742ec59c42721c3@linux-foundation.org> In-Reply-To: <20180724204639.26934-1-cannonmatthews@google.com> References: <20180724204639.26934-1-cannonmatthews@google.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 24 Jul 2018 13:46:39 -0700 Cannon Matthews wrote: > Reimplement clear_gigantic_page() to clear gigabytes pages using the > non-temporal streaming store instructions that bypass the cache > (movnti), since an entire 1GiB region will not fit in the cache anyway. > > ... > > Tested: > Time to `mlock()` a 512GiB region on broadwell CPU > AVG time (s) % imp. ms/page > clear_page_erms 133.584 - 261 > clear_page_nt 34.154 74.43% 67 A gigantic improvement! > --- a/arch/x86/include/asm/page_64.h > +++ b/arch/x86/include/asm/page_64.h > @@ -56,6 +56,9 @@ static inline void clear_page(void *page) > > void copy_page(void *to, void *from); > > +#define __HAVE_ARCH_CLEAR_GIGANTIC_PAGE > +void __clear_page_nt(void *page, u64 page_size); Nit: the modern way is #ifndef __clear_page_nt void __clear_page_nt(void *page, u64 page_size); #define __clear_page_nt __clear_page_nt #endif Not sure why, really. I guess it avoids adding two symbols and having to remember and maintain the relationship between them. > --- /dev/null > +++ b/arch/x86/lib/clear_gigantic_page.c > @@ -0,0 +1,30 @@ > +#include > + > +#include > +#include > +#include > + > +#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS) > +#define PAGES_BETWEEN_RESCHED 64 > +void clear_gigantic_page(struct page *page, > + unsigned long addr, > + unsigned int pages_per_huge_page) > +{ > + int i; > + void *dest = page_to_virt(page); > + int resched_count = 0; > + > + BUG_ON(pages_per_huge_page % PAGES_BETWEEN_RESCHED != 0); > + BUG_ON(!dest); > + > + might_sleep(); cond_resched() already does might_sleep() - it doesn't seem needed here. > + for (i = 0; i < pages_per_huge_page; i += PAGES_BETWEEN_RESCHED) { > + __clear_page_nt(dest + (i * PAGE_SIZE), > + PAGES_BETWEEN_RESCHED * PAGE_SIZE); > + resched_count += cond_resched(); > + } > + /* __clear_page_nt requrires and `sfence` barrier. */ > + wmb(); > + pr_debug("clear_gigantic_page: rescheduled %d times\n", resched_count); > +} > +#endif