From: Daniel Vetter <daniel@ffwll.ch> To: Michal Hocko <mhocko@kernel.org> Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Linux MM" <linux-mm@kvack.org>, intel-gfx <intel-gfx@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Christian König" <christian.koenig@amd.com>, "David Rientjes" <rientjes@google.com>, "Jerome Glisse" <jglisse@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Daniel Vetter" <daniel.vetter@intel.com> Subject: Re: [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail Date: Fri, 23 Nov 2018 14:15:11 +0100 [thread overview] Message-ID: <CAKMK7uGViQT5HPEQzFsAT85gdCr-gw94EB5fMT9eXRBAXambWg@mail.gmail.com> (raw) In-Reply-To: <20181123124358.GJ8625@dhcp22.suse.cz> On Fri, Nov 23, 2018 at 1:43 PM Michal Hocko <mhocko@kernel.org> wrote: > On Fri 23-11-18 13:30:57, Daniel Vetter wrote: > > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote: > > > On Thu 22-11-18 17:51:04, Daniel Vetter wrote: > > > > Just a bit of paranoia, since if we start pushing this deep into > > > > callchains it's hard to spot all places where an mmu notifier > > > > implementation might fail when it's not allowed to. > > > > > > What does WARN give you more than the existing pr_info? Is really > > > backtrace that interesting? > > > > Automated tools have to ignore everything at info level (there's too much > > of that). I guess I could do something like > > > > if (blockable) > > pr_warn(...) > > else > > pr_info(...) > > > > WARN() is simply my goto tool for getting something at warning level > > dumped into dmesg. But I think the pr_warn with the callback function > > should be enough indeed. > > I wouldn't mind s@pr_info@pr_warn@ Well that's too much, because then it would misfire in the oom testcase, where failing is ok (desireble even, we want to avoid blocking after all). So needs to be a switch (or else we need to filter it in results, and that's a bit a maintenance headache from a CI pov). -Danile > > If you wonder where all the info level stuff happens that we have to > > ignore: suspend/resume is a primary culprit (fairly important for > > gfx/desktops), but there's a bunch of other places. Even if we ignore > > everything at info and below we still need filters because some drivers > > are a bit too trigger-happy (i915 definitely included I guess, so everyone > > contributes to this problem). > > Thanks for the clarification. > -- > Michal Hocko > SUSE Labs -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Michal Hocko <mhocko@kernel.org> Cc: "Daniel Vetter" <daniel.vetter@intel.com>, intel-gfx <intel-gfx@lists.freedesktop.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, "Linux MM" <linux-mm@kvack.org>, "Jerome Glisse" <jglisse@redhat.com>, "David Rientjes" <rientjes@google.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Christian König" <christian.koenig@amd.com> Subject: Re: [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail Date: Fri, 23 Nov 2018 14:15:11 +0100 [thread overview] Message-ID: <CAKMK7uGViQT5HPEQzFsAT85gdCr-gw94EB5fMT9eXRBAXambWg@mail.gmail.com> (raw) In-Reply-To: <20181123124358.GJ8625@dhcp22.suse.cz> On Fri, Nov 23, 2018 at 1:43 PM Michal Hocko <mhocko@kernel.org> wrote: > On Fri 23-11-18 13:30:57, Daniel Vetter wrote: > > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote: > > > On Thu 22-11-18 17:51:04, Daniel Vetter wrote: > > > > Just a bit of paranoia, since if we start pushing this deep into > > > > callchains it's hard to spot all places where an mmu notifier > > > > implementation might fail when it's not allowed to. > > > > > > What does WARN give you more than the existing pr_info? Is really > > > backtrace that interesting? > > > > Automated tools have to ignore everything at info level (there's too much > > of that). I guess I could do something like > > > > if (blockable) > > pr_warn(...) > > else > > pr_info(...) > > > > WARN() is simply my goto tool for getting something at warning level > > dumped into dmesg. But I think the pr_warn with the callback function > > should be enough indeed. > > I wouldn't mind s@pr_info@pr_warn@ Well that's too much, because then it would misfire in the oom testcase, where failing is ok (desireble even, we want to avoid blocking after all). So needs to be a switch (or else we need to filter it in results, and that's a bit a maintenance headache from a CI pov). -Danile > > If you wonder where all the info level stuff happens that we have to > > ignore: suspend/resume is a primary culprit (fairly important for > > gfx/desktops), but there's a bunch of other places. Even if we ignore > > everything at info and below we still need filters because some drivers > > are a bit too trigger-happy (i915 definitely included I guess, so everyone > > contributes to this problem). > > Thanks for the clarification. > -- > Michal Hocko > SUSE Labs -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-11-23 13:15 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-22 16:51 [PATCH 0/3] RFC: mmu notifier debug checks Daniel Vetter 2018-11-22 16:51 ` [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail Daniel Vetter 2018-11-22 16:53 ` [Intel-gfx] " Chris Wilson 2018-11-22 16:53 ` Chris Wilson 2018-11-22 16:53 ` [Intel-gfx] " Chris Wilson 2018-11-23 8:49 ` Daniel Vetter 2018-11-23 11:14 ` Michal Hocko 2018-11-22 18:50 ` Koenig, Christian 2018-11-22 18:50 ` Koenig, Christian 2018-11-23 11:15 ` Michal Hocko 2018-11-23 11:15 ` Michal Hocko 2018-11-23 11:15 ` Michal Hocko 2018-11-23 12:30 ` Daniel Vetter 2018-11-23 12:30 ` Daniel Vetter 2018-11-23 12:30 ` Daniel Vetter 2018-11-23 12:43 ` Michal Hocko 2018-11-23 13:15 ` Daniel Vetter [this message] 2018-11-23 13:15 ` Daniel Vetter 2018-11-23 13:30 ` Michal Hocko 2018-11-22 16:51 ` [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable Daniel Vetter 2018-11-22 18:55 ` Koenig, Christian 2018-11-22 18:55 ` Koenig, Christian 2018-11-23 8:46 ` Daniel Vetter 2018-11-23 8:46 ` Daniel Vetter 2018-11-23 8:46 ` Daniel Vetter 2018-11-23 10:14 ` Christian König 2018-11-23 11:12 ` Michal Hocko 2018-11-23 11:12 ` Michal Hocko 2018-11-23 12:38 ` Daniel Vetter 2018-11-23 12:38 ` Daniel Vetter 2018-11-23 12:46 ` Michal Hocko 2018-11-23 13:12 ` Daniel Vetter 2018-11-23 13:12 ` Daniel Vetter 2018-11-23 13:23 ` [Intel-gfx] " Tvrtko Ursulin 2018-11-22 16:51 ` [PATCH 3/3] mm, notifier: Add a lockdep map for invalidate_range_start Daniel Vetter 2018-11-22 16:51 ` Daniel Vetter 2018-11-27 7:49 ` Daniel Vetter 2018-11-27 7:49 ` Daniel Vetter 2018-11-27 7:49 ` Daniel Vetter 2018-11-27 16:49 ` [Intel-gfx] " Chris Wilson 2018-11-27 16:49 ` Chris Wilson 2018-11-27 17:28 ` Daniel Vetter 2018-11-27 17:28 ` Daniel Vetter 2018-11-27 17:33 ` [Intel-gfx] " Chris Wilson 2018-11-27 17:33 ` Chris Wilson 2018-11-27 17:39 ` [Intel-gfx] " Daniel Vetter 2018-11-27 17:39 ` Daniel Vetter 2018-11-27 17:39 ` Daniel Vetter 2018-11-22 18:09 ` ✗ Fi.CI.CHECKPATCH: warning for RFC: mmu notifier debug checks Patchwork 2018-11-22 18:26 ` ✓ Fi.CI.BAT: success " Patchwork 2018-11-23 0:27 ` ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAKMK7uGViQT5HPEQzFsAT85gdCr-gw94EB5fMT9eXRBAXambWg@mail.gmail.com \ --to=daniel@ffwll.ch \ --cc=akpm@linux-foundation.org \ --cc=christian.koenig@amd.com \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jglisse@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=pbonzini@redhat.com \ --cc=rientjes@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.