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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCEBBC433EF for ; Tue, 7 Jun 2022 18:32:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351760AbiFGScq (ORCPT ); Tue, 7 Jun 2022 14:32:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351579AbiFGSaK (ORCPT ); Tue, 7 Jun 2022 14:30:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C816817B85B; Tue, 7 Jun 2022 10:55:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6A059B82370; Tue, 7 Jun 2022 17:55:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E23E0C341C5; Tue, 7 Jun 2022 17:55:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654624536; bh=reSh3o33ZqNq0NqYioUu+8w+hd6FEd7K/Cf3BqMB9N8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Yyp3XO9lLG8PDkjm6oHJrzY+j9nDVAjwZRIrs0a5GrJdii72ofS3KTB8A82pH9RVN NCKyZ8QdUHxR+68D1uCxx5PapObMJ0sr1/8A3G9nWL3KbchYQUdDP/0b421I15aD0R DCppTRSLOZrO5Qh0i5JCx2UefmyC+AESenCI2XjVERO8H2fAIJt3YdRtKTLhT5WgxO V22IKKIjH5iFuSAt3jqpCE9f9fdzRMKUEvXV+WxWqWSvzTLkASKVpXCyauyINWlSJD Xfn0Y2JOAChdGPhjgMPA8PR1tiODdtT6vij1gLI2KWIb6o+UAd0wvxlNe3HCKz9+/u f05G/tVnsFfsQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christian Borntraeger , Alexander Gordeev , Claudio Imbrenda , Heiko Carstens , Sasha Levin , frankja@linux.ibm.com, gor@linux.ibm.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org Subject: [PATCH AUTOSEL 5.17 57/60] s390/gmap: voluntarily schedule during key setting Date: Tue, 7 Jun 2022 13:52:54 -0400 Message-Id: <20220607175259.478835-57-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220607175259.478835-1-sashal@kernel.org> References: <20220607175259.478835-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Christian Borntraeger [ Upstream commit 6d5946274df1fff539a7eece458a43be733d1db8 ] With large and many guest with storage keys it is possible to create large latencies or stalls during initial key setting: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 18-....: (2099 ticks this GP) idle=54e/1/0x4000000000000002 softirq=35598716/35598716 fqs=998 (t=2100 jiffies g=155867385 q=20879) Task dump for CPU 18: CPU 1/KVM R running task 0 1030947 256019 0x06000004 Call Trace: sched_show_task rcu_dump_cpu_stacks rcu_sched_clock_irq update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt do_IRQ ext_int_handler ptep_zap_key The mmap lock is held during the page walking but since this is a semaphore scheduling is still possible. Same for the kvm srcu. To minimize overhead do this on every segment table entry or large page. Signed-off-by: Christian Borntraeger Reviewed-by: Alexander Gordeev Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20220530092706.11637-2-borntraeger@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin --- arch/s390/mm/gmap.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c index dfee0ebb2fac..88f6d923ee45 100644 --- a/arch/s390/mm/gmap.c +++ b/arch/s390/mm/gmap.c @@ -2601,6 +2601,18 @@ static int __s390_enable_skey_pte(pte_t *pte, unsigned long addr, return 0; } +/* + * Give a chance to schedule after setting a key to 256 pages. + * We only hold the mm lock, which is a rwsem and the kvm srcu. + * Both can sleep. + */ +static int __s390_enable_skey_pmd(pmd_t *pmd, unsigned long addr, + unsigned long next, struct mm_walk *walk) +{ + cond_resched(); + return 0; +} + static int __s390_enable_skey_hugetlb(pte_t *pte, unsigned long addr, unsigned long hmask, unsigned long next, struct mm_walk *walk) @@ -2623,12 +2635,14 @@ static int __s390_enable_skey_hugetlb(pte_t *pte, unsigned long addr, end = start + HPAGE_SIZE - 1; __storage_key_init_range(start, end); set_bit(PG_arch_1, &page->flags); + cond_resched(); return 0; } static const struct mm_walk_ops enable_skey_walk_ops = { .hugetlb_entry = __s390_enable_skey_hugetlb, .pte_entry = __s390_enable_skey_pte, + .pmd_entry = __s390_enable_skey_pmd, }; int s390_enable_skey(void) -- 2.35.1