Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1259828ybl; Fri, 23 Aug 2019 16:23:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqwTCqA4jfy0oQndjvduWLhxlQC86cKbwIXzGkCoIkUBJuYpKtF0TuxLdhXuLst7Jh5Vs6mC X-Received: by 2002:a17:902:7842:: with SMTP id e2mr7286796pln.49.1566602628371; Fri, 23 Aug 2019 16:23:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566602628; cv=none; d=google.com; s=arc-20160816; b=hZdRIp+7FzThTDZinc8p/ZWRHnT9sXSY7sJcxAYTmaFrmccHX46UJeMTxOGfdfhmqp PS03J4SbAWRPW6+N/uQ5d7NVQe/0DDbZUMFeHPhZhon/WJFmD2LiVxqmjXeiPky3NzEz idvDkTf0rfVo0iigRG+v2e7you5/FC1C56VB0fIqzd7mi4deoBm/8mLc8zMa6UduyHdN QHDQjTnxcpN8BxnUtkjkBEYvsrIQ3L2BWEo9wKYwfGBShYAr5Rjnw9bNwNvrejuxaZ3g nfcPi3DTJ7Bn24CRtvmRJWEnpTk1EMJlyuufIhlENQUKrnHiy8lta9dPYr9hdQ/XAyn6 Lmtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Jw7xTqZljvWDt+gH2lHnnIUkh+OWb2dqWCVggLcTb1s=; b=r3eilBDniLy/mNpXxz0+cZlXnhMawknzaTK345jh+oo19BGYTMfdPbLfd+TdCRZwIp 2dkosGQpSdGALBElA9ZIQugNX6ZJsfscOycUOZ89JSwJFfkA88V2c0LaEQK054UhDVyy NTzkw1emR44uFYdh0mlUL91fBwoVojio/HHbogelMFxU38iZV3wvp73xoqxzDs7zU0Iz P9bfakf/eJGFSojj1FaQZtgNE/+aVM4sYjPzJBDIy/jFg4WcP5l8fIrEDFTXjV66skeS 6Oro96lfmd32wsDimx0eAjhmtYkwev34IkofUPHXmYnJKjMC9yLrryyUruUzLf9hVJoN q6rA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=gyrMKzTu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w3si3684807plp.182.2019.08.23.16.23.33; Fri, 23 Aug 2019 16:23:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=gyrMKzTu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405677AbfHWNnA (ORCPT + 99 others); Fri, 23 Aug 2019 09:43:00 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:43910 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731976AbfHWNnA (ORCPT ); Fri, 23 Aug 2019 09:43:00 -0400 Received: by mail-oi1-f195.google.com with SMTP id y8so7004359oih.10 for ; Fri, 23 Aug 2019 06:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jw7xTqZljvWDt+gH2lHnnIUkh+OWb2dqWCVggLcTb1s=; b=gyrMKzTuaWrnNIRBDm50i6quBqIz1bhUm1Gm6/8s2kaFviG+TeyKizbVwp8QsZDsg9 cB0yBjxUh49n7gzOZcU+eGE8vbuKolbVIShRQc6ouMetE6nFGOVR3MppH+/tnYO3Zrlc UH0SHALg7tcmzdDG2FTfNdvvTV0I/BMmNjbSw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jw7xTqZljvWDt+gH2lHnnIUkh+OWb2dqWCVggLcTb1s=; b=V6vSEG+3EbY9tl2IqrUJfWM+zs3L1C/YQu4WJ5ZvNnJL6jF1JlJY0nuiwno+KBTT2a NOemhk20jjgQA8MD2xNHs7cVGEPalkwEYZj/uWmeYn9H4HrljYcN0vhY7gnxwn1TZaSP xc8qWPyo+NhvX1skLP0I5stpyHmQlEygl0xa26maIainclpwKXdRCtePdezO8aiAznMn 0rDQqcZ4l4E4zOMOUCtmW3zeh1MnHVU7xsIoqr6NBmibqV1753grAWEjHph7luofL2+a m49qguxRag+WLA8Ec5j/6jUgr74jv2frdWbalOOlct3lOPeYcVrQjo2Zx8FY/C8uPnB8 zi5w== X-Gm-Message-State: APjAAAWLH/fh+LXMebTR8gRmK/dh/dp6wH8igC6xEBwGAcntr0p1+0My YKbQ4Swnrfbn1PBfXd5oUK6VagOvO4FA9JsR9ZzMuw== X-Received: by 2002:aca:da08:: with SMTP id r8mr3001623oig.101.1566567779012; Fri, 23 Aug 2019 06:42:59 -0700 (PDT) MIME-Version: 1.0 References: <20190820081902.24815-1-daniel.vetter@ffwll.ch> <20190820081902.24815-4-daniel.vetter@ffwll.ch> <20190820202440.GH11147@phenom.ffwll.local> <20190822161428.c9e4479207386d34745ea111@linux-foundation.org> <20190823121234.GB12968@ziepe.ca> In-Reply-To: <20190823121234.GB12968@ziepe.ca> From: Daniel Vetter Date: Fri, 23 Aug 2019 15:42:47 +0200 Message-ID: Subject: Re: [PATCH 3/4] kernel.h: Add non_block_start/end() To: Jason Gunthorpe Cc: Andrew Morton , LKML , Linux MM , DRI Development , Intel Graphics Development , Peter Zijlstra , Ingo Molnar , Michal Hocko , David Rientjes , =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Masahiro Yamada , Wei Wang , Andy Shevchenko , Thomas Gleixner , Jann Horn , Feng Tang , Kees Cook , Randy Dunlap , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 23, 2019 at 2:12 PM Jason Gunthorpe 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 wrote: > > > > > > On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter 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