On Fri, Aug 23, 2019 at 2:12 PM Jason Gunthorpe <jgg@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter <daniel@xxxxxxxx> 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
