On Fri, Aug 23, 2019 at 2:12 PM Jason Gunthorpe jgg@ziepe.ca wrote:
On Fri, Aug 23, 2019 at 10:34:01AM +0200, Daniel Vetter wrote:
On Fri, Aug 23, 2019 at 1:14 AM Andrew Morton akpm@linux-foundation.org wrote:
On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter daniel@ffwll.ch wrote:
Hi Peter,
Iirc you've been involved at least somewhat in discussing this. -mm folks are a bit undecided whether these new non_block semantics are a good idea. Michal Hocko still is in support, but Andrew Morton and Jason Gunthorpe are less enthusiastic. Jason said he's ok with merging the hmm side of this if scheduler folks ack. If not, then I'll respin with the preempt_disable/enable instead like in v1.
I became mollified once Michel explained the rationale. I think it's OK. It's very specific to the oom reaper and hopefully won't be used more widely(?).
Yeah, no plans for that from me. And I hope the comment above them now explains why they exist, so people think twice before using it in random places.
I still haven't heard a satisfactory answer why a whole new scheme is needed and a simple:
if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP)) preempt_disable()
isn't sufficient to catch the problematic cases during debugging?? IMHO the fact preempt is changed by the above when debugging is not material here. I think that information should be included in the commit message at least.
But if sched people are happy then lets go ahead. Can you send a v2 with the check encompassing the invalidate_range_end?
Yes I will resend with this patch plus the next, amended as we discussed, plus the might_sleep annotations. I'm assuming the lockdep one will land, so not going to resend that. -Daniel
On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
I'm assuming the lockdep one will land, so not going to resend that.
I was assuming you'd wake the might_lock_nested() along with the i915 user through the i915/drm tree. If want me to take some or all of that, lemme know.
On Fri, Aug 23, 2019 at 4:06 PM Peter Zijlstra peterz@infradead.org wrote:
On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
I'm assuming the lockdep one will land, so not going to resend that.
I was assuming you'd wake the might_lock_nested() along with the i915 user through the i915/drm tree. If want me to take some or all of that, lemme know.
might_lock_nested() is a different patch series, that one will indeed go in through the drm/i915 tree, thx for the ack there. What I meant here is some mmu notifier lockdep map in this series that Jason said he's going to pick up into hmm.git. I'm doing about 3 or 4 different lockdep annotations series in parallel right now :-) -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Peter Zijlstra