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 AFD0DC433EF for ; Wed, 6 Apr 2022 18:59:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230154AbiDFTBV (ORCPT ); Wed, 6 Apr 2022 15:01:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230146AbiDFS6U (ORCPT ); Wed, 6 Apr 2022 14:58:20 -0400 Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BADC21F6217 for ; Wed, 6 Apr 2022 10:53:35 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id s7so5684728qtk.6 for ; Wed, 06 Apr 2022 10:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UiC0JZZNX3Tmz74Za2QGi0YjgPWaNriTzAia+mIG/oY=; b=C8Z9DYmcvxvJu8NY+MYMQtX06XDHFQ8K7wmWpgt+e7UvuTJ9kBW6rgJ4m96ItAT6bC agSP0mlkb7pnOPpK4P5qXOxdL3bq3763M5W3mQub8hSZw4EHWvaiGixVMKZjjpkduDrG /01OoPFxfig9PKbGV/F3KE1OujzAGwrfqLQiAruhJhtDtf9ijrhVvcQB6SLC0vb+q3qf 8Vl9LEL+vckhVErsWsETDcjgIWL4qfXEq9DCiY2YNiB3pdXE+lO4IuMvWvz1EfPk6J/t DV0ZhLSsIxbw3Pqo48d1dCeDRNuY0lzlWrixn45pwenckWRpx7+MZxNkmc5uxMQamJBA Bm8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UiC0JZZNX3Tmz74Za2QGi0YjgPWaNriTzAia+mIG/oY=; b=ErpzmZQzutElDQ2b0Xmf7qcL0nAvSl/FlTWcxLmKJ7cbxtKsOv9PIZ2uN9M/pTjyOF 26XRdg6scNklGoUEgghbCB0nCLuZeLSE18f4UpnN80s3wsEy1vIGryietx8hopSJXezM PkpYo2t9RZPOXJ25QlVUfWDps4bOf/95CqEph54wxTRBoPC7PGOVcWR3x4Eg3rH3Ijgv aGRY5/glc73xPNMnbi571IXYRZH8OW6Jw4mSqTQMnUcXYfT5ZVbrs5zk9APQmb3dGvNd 0ENNtk0V90wrUXJoTbxTGY3b9phYKi5IW+pepikj7OmVNjg/T422Q5RHJofb5j44iRDp JCsw== X-Gm-Message-State: AOAM533EAfuEAvVnHo3MZR4qTUNq98eaX+GUAPOrxAcH4zfhuJRb5W52 fKYRlycDkbTqM7YJxhn2brJIHBriF83ucg+ziAEXZg== X-Google-Smtp-Source: ABdhPJwOnUHmEK3nL1Hw0/iJrblnXqISxL1gjp5QrgobTxIRsSlbBb1hCnBusAh4f2TNJVRB/0hdR0CBT2U4iymcC9w= X-Received: by 2002:a05:622a:610:b0:2e2:694:38c6 with SMTP id z16-20020a05622a061000b002e2069438c6mr8559136qta.458.1649267614742; Wed, 06 Apr 2022 10:53:34 -0700 (PDT) MIME-Version: 1.0 References: <20220330164306.2376085-1-pgonda@google.com> In-Reply-To: From: Mingwei Zhang Date: Wed, 6 Apr 2022 10:53:23 -0700 Message-ID: Subject: Re: [PATCH] KVM: SEV: Add cond_resched() to loop in sev_clflush_pages() To: Sean Christopherson Cc: Peter Gonda , kvm , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sean, > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > > index 75fa6dd268f0..c2fe89ecdb2d 100644 > > > --- a/arch/x86/kvm/svm/sev.c > > > +++ b/arch/x86/kvm/svm/sev.c > > > @@ -465,6 +465,7 @@ static void sev_clflush_pages(struct page *pages[], unsigned long npages) > > > page_virtual = kmap_atomic(pages[i]); > > > clflush_cache_range(page_virtual, PAGE_SIZE); > > > kunmap_atomic(page_virtual); > > > + cond_resched(); > > > > If you add cond_resched() here, the frequency (once per 4K) might be > > too high. You may want to do it once per X pages, where X could be > > something like 1G/4K? > > No, every iteration is perfectly ok. The "cond"itional part means that this will > reschedule if and only if it actually needs to be rescheduled, e.g. if the task's > timeslice as expired. The check for a needed reschedule is cheap, using > cond_resched() in tight-ish loops is ok and intended, e.g. KVM does a reched > check prior to enterring the guest. Double check on the code again. I think the point is not about flag checking. Obviously branch prediction could really help. The point I think is the 'call' to cond_resched(). Depending on the kernel configuration, cond_resched() may not always be inlined, at least this is my understanding so far? So if that is true, then it still might not always be the best to call cond_resched() that often.