[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201027201730.kyusnssnrict75bh@linux-p48b.lan>
Date: Tue, 27 Oct 2020 13:17:30 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Sean Christopherson <sean.j.christopherson@...el.com>
Cc: Ben Gardon <bgardon@...gle.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Peter Shier <pshier@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>
Subject: Re: [PATCH 3/3] sched: Add cond_resched_rwlock
On Tue, 27 Oct 2020, Sean Christopherson wrote:
>On Tue, Oct 27, 2020 at 09:49:50AM -0700, Ben Gardon wrote:
>> Rescheduling while holding a spin lock is essential for keeping long
>> running kernel operations running smoothly. Add the facility to
>> cond_resched rwlocks.
Nit: I would start the paragraph with 'Safely rescheduling ...'
While obvious when reading the code, 'Rescheduling while holding
a spin lock' can throw the reader off.
>
>This adds two new exports and two new macros without any in-tree users, which
>is generally frowned upon. You and I know these will be used by KVM's new
>TDP MMU, but the non-KVM folks, and more importantly the maintainers of this
>code, are undoubtedly going to ask "why". I.e. these patches probably belong
>in the KVM series to switch to a rwlock for the TDP MMU.
>
>Regarding the code, it's all copy-pasted from the spinlock code and darn near
>identical. It might be worth adding builder macros for these.
Agreed, all three could be nicely consolidated. Otherwise this series looks
sane, feel free to add my:
Acked-by: Davidlohr Bueso <dbueso@...e.de>
Powered by blists - more mailing lists