Re: [Intel-gfx] Info: mapping multiple BARs. Your kernel is fine.

On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote: As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am not so sure this is all related to the uncore IMC support, though. Unstable

Re: [Intel-gfx] Info: mapping multiple BARs. Your kernel is fine.

On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote: On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org wrote: On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote: As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Thu, Sep 12, 2013 at 05:36:43PM +0200, Daniel Vetter wrote: The set_need_resched in i915_gem.c:i915_gem_fault can actually be removed. It was there to give the error handler a chance to sneak in and reset the hw/sw tracking when the gpu is dead. That hack goes back to the days when the

[Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

Hi Dave, So I'm poking around the preemption code and stumbled upon: drivers/gpu/drm/i915/i915_gem.c:set_need_resched(); drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched(); drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();

Re: [Intel-gfx] [PATCH 2/2] drm/udl: rip out set_need_resched

drop it. Reported-by: Peter Zijlstra pet...@infradead.org Thanks! Acked-by: Peter Zijlstra pet...@infradead.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

-point out. Reported-by: Peter Zijlstra pet...@infradead.org Thanks! Acked-by: Peter Zijlstra pet...@infradead.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Thu, Sep 12, 2013 at 05:11:25PM +0200, Maarten Lankhorst wrote: Op 12-09-13 17:06, Peter Zijlstra schreef: Hi Dave, So I'm poking around the preemption code and stumbled upon: drivers/gpu/drm/i915/i915_gem.c:set_need_resched(); drivers/gpu/drm/ttm/ttm_bo_vm.c

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Thu, Sep 12, 2013 at 05:35:43PM +0100, Chris Wilson wrote: Not quite, as it would be possible for the evil userspace to trigger a GPU hang that would cause the sane userspace to spin indefinitely waiting for the error recovery to kick in. So with FIFOn+1 preempting FIFOn its a live-lock

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote: if (!bo_tryreserve()) { up_read mmap_sem(); // Release the mmap_sem to avoid deadlocks. bo_reserve(); // Wait for the BO to become available (interruptible) bo_unreserve(); // Where is

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote: On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra pet...@infradead.org wrote: On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote: if (!bo_tryreserve()) { up_read mmap_sem(); // Release the mmap_sem to avoid

Re: [Intel-gfx] [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

So I've not yet went through the entire series; but I'm wondering if its at all possible to re-use some of this work: lkml.kernel.org/r/1428453299-19121-1-git-send-email-suka...@linux.vnet.ibm.com That's for a Power8 HV call that can basically return an array of values; which on a superficial

Re: [Intel-gfx] [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote: I've changed the uapi for configuring the i915_oa specific attributes when calling perf_event_open(2) whereby instead of cramming lots of bitfields into the perf_event_attr config members, I'm now daisy-chaining a

Re: [Intel-gfx] [PATCH 2/5] mm: Refactor remap_pfn_range()

On Tue, Apr 07, 2015 at 01:27:21PM -0700, Andrew Morton wrote: On Tue, 7 Apr 2015 17:31:36 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: In preparation for exporting very similar functionality through another interface, gut the current remap_pfn_range(). The motivating factor here

Re: [Intel-gfx] [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote: On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra pet...@infradead.org wrote: On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote: I've changed the uapi for configuring the i915_oa specific attributes when calling

Re: [Intel-gfx] [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

On Thu, May 21, 2015 at 12:17:48AM +0100, Robert Bragg wrote: So for me the 'natural' way to represent this in perf would be through event groups. Create a perf event for every single event -- yes this is 53 events. So when I was first looking at this work I had considered the

Re: [Intel-gfx] [RFC 0/6] Non perf based Gen Graphics OA unit driver

On Fri, Oct 16, 2015 at 12:02:28PM +0200, Ingo Molnar wrote: > > * Peter Zijlstra <pet...@infradead.org> wrote: > > > > - We may be making some technical compromises a.t.m for the sake of > > > using perf. > > > > > > perf_eve

Re: [Intel-gfx] [RFC 0/6] Non perf based Gen Graphics OA unit driver

On Tue, Sep 29, 2015 at 03:39:03PM +0100, Robert Bragg wrote: > - We're bridging two complex architectures > > To review this work I think it will be relevant to have a good > general familiarity with Gen graphics (e.g. thinking about the OA > unit's interaction with the command

Re: [Intel-gfx] [RFC 4/6] drm/i915: Add i915 perf event for Haswell OA unit

On Tue, Sep 29, 2015 at 10:55:39PM +0800, kbuild test robot wrote: > Hi Robert, > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, please > ignore] > > config: i386-defconfig (attached as .config) > reproduce: > git checkout a1d59679ae8f3e7e7659e9723ae3fc69af2532e6 > #

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Enable lockless lookup of request tracking via RCU

On Wed, Jan 06, 2016 at 09:06:58AM +0100, Daniel Vetter wrote: > This pretty much went over my head ;-) What I naively hoped for is that > kfree() on an rcu-freeing slab could be tought to magically stall a bit > (or at least expedite the delayed freeing) if we're piling up too many > freed

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Enable lockless lookup of request tracking via RCU

On Tue, Jan 05, 2016 at 03:59:51PM +0100, Daniel Vetter wrote: > On Wed, Dec 23, 2015 at 01:35:54PM +, Chris Wilson wrote: > > If we enable RCU for the requests (providing a grace period where we can > > inspect a "dead" request before it is freed), we can allow callers to > > carefully

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Enable lockless lookup of request tracking via RCU

On Tue, Jan 05, 2016 at 04:02:13PM +0100, Peter Zijlstra wrote: > > Shouldn't the slab subsystem do this for us if we request it delays the > > actual kfree? Seems like a core bug to me ... Adding more folks. > > note that sync_rcu() can take a terribly long time.. but yes, I

Re: [Intel-gfx] [PATCH] mutex: Report recursive ww_mutex locking early

deadlock discovery to the first action when taking the ww_mutex. > > > > Testcase: igt/kms_cursor_legacy I've no idea what this tag is or where to find the actual testcase, so I've killed it. > > Suggested-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > > S

Re: [Intel-gfx] [PATCH] mutex: Report recursive ww_mutex locking early

On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote: > Patch not applied, SCHED_RR: ww_mutex isn't RT aware at all; its one of the things I still have on a todo list. Should I look harder at finding time for this? ___ Intel-gfx mailing

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote: > Instead of implementing a custom locked reference counting, use lockref. > > Current implementation leads to a deadlock splat on Intel SKL platforms > when lockdep debugging is enabled. > > This is due to few of CPUfreq drivers

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote: > On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote: > > Instead of implementing a custom locked reference counting, use lockref. > > > > Current implementation leads to a deadlock splat on Intel S

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On Tue, Feb 16, 2016 at 10:49:36AM +0200, Joonas Lahtinen wrote: > I originally thought of implementing this more similar to what you > specify, but then I came across a discussion in the mailing list where > it was NAKed adding more members to task_struct; > >

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote: > Quoting my original patch; > > "See the Bugzilla link for more details. If its not in the Changelog it doesn't exist. Patches should be self contained and not refer to external sources for critical information.

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On Wed, Feb 17, 2016 at 02:47:31PM +0200, Joonas Lahtinen wrote: > On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote: > > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote: > > > Quoting my original patch; > > > > > > "See the Bugzil

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote: > And for context we're hitting this on CI in a bunch of our machines, which What's CI ? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On Wed, Feb 17, 2016 at 05:33:51PM +0100, Daniel Vetter wrote: > On Wed, Feb 17, 2016 at 05:14:57PM +0100, Peter Zijlstra wrote: > > On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote: > > > And for context we're hitting this on CI in a bunch of our machines, which

Re: [Intel-gfx] drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote: > We are only documenting that the read is outside of the lock, and do not > require strict ordering on the operation. In this case the more relaxed > lockless_dereference() will suffice. No, no, no... This is 'broken'.

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote: > If my upcoming testing of the two changes together pans out, I will > give you a Tested-by -- I am guessing that you don't want to wait > until the next merge window for these changes. I was planning to stuff them in

Re: [Intel-gfx] linux-next: build failure after merge of the tip tree (from the drm-intel tree)

On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote: > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index d3502c0603e5..1f91f187b2a8 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3290,7 +3290,7 @@

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > You're talking about: > > > > lkml.kernel.org/r/20161007154351.gl3...@twins.programming.kicks-ass.net > > > > ? I got no feedback from you DRM guys on that so I kinda forgot about > > that in the hope we'd not have to do this

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > Now, I know you're working on getting rid of this entirely for i915, but > > what about that MSM driver? Will we continue to need it there, is > > anybody actually maintaining that thing? > > Rob Clark is, and since he's a one-man

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > FIXME: Add owner of second tree to To: > >Add author(s)/SOB of conflicting commits. > > > > Today's linux-next merge of the tip tree got

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Wed, Apr 12, 2017 at 04:30:32PM +0300, Jani Nikula wrote: > On Wed, 12 Apr 2017, Peter Zijlstra <pet...@infradead.org> wrote: > > On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote: > >> The issue is describe more in detail here: > >> https://bug

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote: > > > So, why is this only affecting the Core 2 Duo? > > > > Core2 doesn't have a usable TSC and would revert to the slow path. I'll > > have another look at that patch. > > > > So, by default, it is using the hpet clock source.

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote: > > > On 12/04/17 17:32, Peter Zijlstra wrote: > > On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote: > > > > > > > So, why is this only affecting the Core 2 Duo? > > > > &

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote: > Hi, > > We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up > to our i915 pre-merge CI system, that has started to give unstable results > after commit: > > commit

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Thu, Apr 20, 2017 at 07:19:50PM +0200, Peter Zijlstra wrote: > Just for my sanity, could you confirm "tsc=unstable" (which requires the > patch) actually works for you? Also, could you get me the dmesg of a 'broken' boot? ___ Intel-

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Thu, Apr 13, 2017 at 03:30:25PM +0300, Martin Peres wrote: > On 13/04/17 14:48, Peter Zijlstra wrote: > > On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote: > > > > > Good to know. Is there a way to disable this behaviour, as a workaround > > &

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote: > Good to know. Is there a way to disable this behaviour, as a workaround for > our CI system until a proper fix lands? We already pushed locally the revert > for this patch, but that may affect other platforms which do not exhibit the

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Tue, Apr 18, 2017 at 05:53:56PM +0200, Peter Zijlstra wrote: > On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote: > > Sorry Peter, I still see regression on the Core2 machine, with your patch. > > > > Blergh, ok. I'll see if I can dig out an actual Core2 m

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote: > Sorry Peter, I still see regression on the Core2 machine, with your patch. > Blergh, ok. I'll see if I can dig out an actual Core2 machine somewhere. I should have enough parts about.

Re: [Intel-gfx] [PATCH] drm/i915: annote drop_caches debugfs interface with lockdep

On Sun, Mar 12, 2017 at 09:53:40PM +0100, Daniel Vetter wrote: > Peter/Ingo, > > We want this to validate the i915 shrinker locking in our fast tests > without thrashing badly (that takes too long, we can only thrash in > the extended runs). Can you pls take a look and if it's ok ack for >

Re: [Intel-gfx] [PATCH] drm/i915: annote drop_caches debugfs interface with lockdep

On Mon, Mar 13, 2017 at 09:15:17AM +0100, Daniel Vetter wrote: > On Mon, Mar 13, 2017 at 09:01:57AM +0100, Peter Zijlstra wrote: > > On Sun, Mar 12, 2017 at 09:53:40PM +0100, Daniel Vetter wrote: > > > > > Peter/Ingo, > > > > > > We want this to vali

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote: > A more complete solution would be to do the mutex_init in the drm core > only for legacy drivers, plus add it to each modern driver that still > needs it, which would also give each its own lockdep key. Trying to do > that

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

On Mon, Jul 17, 2017 at 05:06:42PM +0200, Daniel Vetter wrote: > On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra <pet...@infradead.org> wrote: > > On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote: > >> A more complete solution would be to do the mutex_init i

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Sat, Aug 12, 2017 at 02:15:13AM +, Rogozhkin, Dmitry V wrote: > $ perf stat -e instructions,i915/rcs0-busy/ workload.sh > <... wrokload.sh output...> > > Performance counter stats for 'workload.sh': > 1,204,616,268 instructions > 0 i915/rcs0-busy/ > >

Re: [Intel-gfx] [RFC] mm, drm/i915: Mark pinned shmemfs pages as unevictable

On Tue, Jun 06, 2017 at 02:14:18PM +0200, Michal Hocko wrote: > That is certainly desirable. Peter has proposed a generic pin_page (or > similar) API. What happened with it? I got stuck on converting IB ... and I think someone thereafter made an ever bigger mess of the pinning stuff. I don't

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 11:06:37AM +0200, Daniel Vetter wrote: > I pondered whether we should annotate engine->submit_request as __rcu > and use rcu_assign_pointer and rcu_dereference on it. But the reason > behind those is to make sure the compiler/cpu barriers are there for > when you have an

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 12:12:41PM +0200, Thomas Gleixner wrote: > So if you don't have a compelling technical reason to > use it, then it _is_ the wrong tool. This. stop_machine() effectively takes down _all_ CPUs for the duration of your callback. That is something you really should avoid at

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Tue, Aug 29, 2017 at 07:16:31PM +, Rogozhkin, Dmitry V wrote: > > Pretty strict, people tend to get fairly upset every time we leak stuff. > > In fact Debian and Android carry a perf_event_paranoid patch that > > default disables _everything_ :-( > > Can you say more on that for Debian and

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Wed, Aug 23, 2017 at 05:51:38PM +, Rogozhkin, Dmitry V wrote: > Anyhow, returning to the metrics i915 exposes. Some metrics are just > exposure of some counters supported already inside i915 PMU which do not > require any special sampling: at any given moment you can request the > counter

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Wed, Aug 23, 2017 at 05:51:38PM +, Rogozhkin, Dmitry V wrote: > https://patchwork.freedesktop.org/patch/171953/. This patch makes 'perf > stat -e i915/rcs0-busy/' to error out and supports 'perf stat -e > i915/rcs0-busy/ -a -C0'. I still think I miss something since 'perf stat > -e

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Wed, Aug 23, 2017 at 05:51:38PM +, Rogozhkin, Dmitry V wrote: > > The above command tries to add an event 'i915/rcs0-busy/' to a task. How > > are i915 resource associated to any one particular task? > > Currently in no way, they are global. Right. So no per DRM context things. Can you

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Wed, Aug 23, 2017 at 05:51:38PM +, Rogozhkin, Dmitry V wrote: > And there is another problem associated with the "perf stat -e > -a": since 8 events are initialized, I get metric values multiplied by > 8. How I am supposed to fix that? I suspect that this is somehow related > to cpumask

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Wed, Aug 23, 2017 at 06:38:05PM +, Rogozhkin, Dmitry V wrote: > On Wed, 2017-08-23 at 20:04 +0200, Peter Zijlstra wrote: > > On Wed, Aug 23, 2017 at 05:51:38PM +, Rogozhkin, Dmitry V wrote: > > > > > > The above command tries to add an event 'i915

Re: [Intel-gfx] [RFC] mm, drm/i915: Mark pinned shmemfs pages as unevictable

On Mon, Aug 21, 2017 at 04:03:31PM +0100, Chris Wilson wrote: > My googlefu says "[RFC][PATCH 1/5] mm: Introduce VM_PINNED and > interfaces" is the series, and it certainly targets the very same > problem. > > Peter, is that the latest version? Probably, I ran into the Infiniband code and

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Wed, Aug 23, 2017 at 07:00:33PM +, Rogozhkin, Dmitry V wrote: > On Wed, 2017-08-23 at 20:22 +0200, Peter Zijlstra wrote: > > On Wed, Aug 23, 2017 at 05:51:38PM +, Rogozhkin, Dmitry V wrote: > > > > > Anyhow, returning to the metrics i915 exposes. Some metrics

Re: [Intel-gfx] [RFC v2 2/3] drm/i915/pmu: serve global events and support perf stat

On Wed, Aug 23, 2017 at 11:38:43PM +, Rogozhkin, Dmitry V wrote: > On Wed, 2017-08-23 at 08:26 -0700, Dmitry Rogozhkin wrote: > > +static cpumask_t i915_pmu_cpumask = CPU_MASK_CPU0; > > Peter, this hardcoding of cpumask to use CPU0 works, but should I > implement something smarter or this

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

On Mon, Aug 28, 2017 at 10:43:17PM +, Rogozhkin, Dmitry V wrote: > Hi Peter, > > I have updated my fixes to Tvrtko's PMU, they are here: > https://patchwork.freedesktop.org/series/28842/, and I started to check > whether we will be able to cover all the use cases for this PMU which we > had

Re: [Intel-gfx] [RFC v2 2/3] drm/i915/pmu: serve global events and support perf stat

On Wed, Aug 30, 2017 at 05:24:30PM +, Rogozhkin, Dmitry V wrote: > Ok... but they could register for just cpu0. Besides, it looks like on > Linux cpu0 can't go offline at all at least of x86 architecture. Peter, > could you, please, clarify the reasoning to register designated readers > of

Re: [Intel-gfx] [RFC v2 2/3] drm/i915/pmu: serve global events and support perf stat

On Wed, Aug 30, 2017 at 05:24:30PM +, Rogozhkin, Dmitry V wrote: > I figured out how to track cpus online/offline status in PMU. Here is a > question however. What is the reason for uncore PMUs (cstate.c for > example) to register for cpus other than cpu0? I see it registers for > first thread

Re: [Intel-gfx] [RFC v2 3/3] drm/i915/pmu: deny perf driver level sampling of i915 PMU

On Wed, Aug 23, 2017 at 11:43:13PM +, Rogozhkin, Dmitry V wrote: > Hi Chris, > > Why we had event->hw->hrtimer in i915 PMU? Was there any particular > reason? You had some use case which did not work? Some uncore drivers have a hrtimer to poll the counter to deal with counter overflow. This

Re: [Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote: > cross-release ftl > > From Chris: > > "Fwiw, this isn't cross-release but us reloading the module many times, > creating a whole host of new lockclasses. Even more fun is when the > module gets a slightly different address and the

Re: [Intel-gfx] [PATCH] drm/i915: properly init lockdep class

On Wed, Dec 13, 2017 at 06:36:33PM +0100, Sebastian Andrzej Siewior wrote: > +peterz > context: http://www.spinics.net/lists/intel-gfx/msg149011.html > > On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote: > > On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote: > > > On

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

ue to the many entry points this is slightly > tedious. > > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > Cc: Marta Lofstedt <marta.lofst...@intel.com> > Cc: Byungchul Park <byungchul.p...@lge.com> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Peter Zijlstra

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

On Thu, Dec 07, 2017 at 09:56:57PM +0100, Daniel Vetter wrote: > On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote: > > Is what it says I suppose. Now I don't know enough about that i915 code > > to say if that breadcrumbs_signal thread can ever trigger a fault or

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

On Fri, Dec 08, 2017 at 05:36:28PM +0100, Daniel Vetter wrote: > Aside: Could/should we take some fake lockdep locks around these > callbacks, since not all drivers call them from a hardirq context? Just to > validate that everyone follows the contract. What I typically do is use

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote: > Since -rc1 we're hitting a bunch of lockdep splats using the new > cross-release stuff around the 2 kthread completions. In all cases > they are because totally independent uses of kthread are mixed up by > lockdep into the same

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

On Thu, Dec 07, 2017 at 03:58:28PM +0100, Daniel Vetter wrote: > [ 85.069417] gem_exec_captur/2810 is trying to acquire lock: > [ 85.069419] ((completion)>parked){+.+.}, at: [] > kthread_park+0x3d/0x50 > [ 85.069426] >but task is already holding lock: > [ 85.069428]

Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > For situations where sysadmins might want to allow different level of > of access control for different PMUs, we start creating per-PMU > perf_event_paranoid controls in sysfs.

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote: > Avoids complaints from gcc about ambiguous else clauses. Is that a new thing? I'm fairly sure I've never seen it do that, > Signed-off-by: Daniel Vetter > Cc: Andrew Morton > Cc: Peter Zijlstra > --- > includ

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote: > for_each_something(foo) > if (foo->bla) > call_bla(foo); > else > call_default(foo); Note that the kernel coding style 'discourages' this style and would like you to write:

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 05:00:07PM +0200, Daniel Vetter wrote: > On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra wrote: > > On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote: > >> #define for_each_node_with_cpus(node)\ > >>

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote: > for_each_something(foo) > if (foo->bla) > call_bla(foo); > else > call_default(foo); > > Totally contrived, but this complains. Liberally sprinkling {} also shuts > up the compiler, but it's a

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

On Thu, Mar 15, 2018 at 11:31:57AM +0100, Daniel Vetter wrote: > Is there any progress on getting cross-release enabled again? Not yet, I'm still fighting the meltdown/spectre induced backlog. We'll get to it eventually. ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

On Wed, Apr 11, 2018 at 09:26:11AM -0700, Francisco Jerez wrote: > "just like" here is possibly somewhat unfair to the schedutil governor, > admittedly its progressive IOWAIT boosting behavior seems somewhat less > wasteful than the intel_pstate non-HWP governor's IOWAIT boosting > behavior, but

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

On Thu, Apr 12, 2018 at 11:34:54AM -0700, Francisco Jerez wrote: > The reason for the energy efficiency problem of iowait boosting is > precisely the greater oscillation between turbo and idle. Say that > iowait boost increases the frequency by a factor alpha relative to the > optimal frequency

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

On Fri, Apr 13, 2018 at 06:57:39PM -0700, Francisco Jerez wrote: > Peter Zijlstra <pet...@infradead.org> writes: > > > On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote: > >> Actually assuming that a single geometric feature of the power curve is &g

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote: > Actually assuming that a single geometric feature of the power curve is > known -- it being convex in the frequency range allowed by the policy > (which is almost always the case, not only for Intel CPUs), the optimal > frequency

Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()

On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote: > I do not see any scheduler guys Cced and it would be really great to get > their opinion here. > > On Mon 10-12-18 11:36:39, Daniel Vetter wrote: > > In some special cases we must not block, but there's not a > > spinlock,

Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()

On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote: > > OK, no real objections to the thing. Just so long we're all on the same > > page as to what it does and doesn't do ;-) > > I am not really sure whether there are other potential users besides > this one and whether the check as

Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()

On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote: > On Mon 10-12-18 15:47:11, Peter Zijlstra wrote: > > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote: > > > I do not see any scheduler guys Cced and it would be really great to get > &

Re: [Intel-gfx] [RFC][PATCH] wake_up_var() memory ordering

(sorry for cross-posting to moderated lists btw, I've since acquired a patch to get_maintainers.pl that wil exclude them in the future) On Tue, Jun 25, 2019 at 08:51:01AM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > I tried using wake_up_var() today and accident

Re: [Intel-gfx] [RFC][PATCH] wake_up_var() memory ordering

On Tue, Jun 25, 2019 at 11:19:35AM +0200, Andreas Gruenbacher wrote: > > diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c > > index cf4c767005b1..29ea5da7 100644 > > --- a/fs/gfs2/glops.c > > +++ b/fs/gfs2/glops.c > > @@ -227,6 +227,7 @@ static void gfs2_clear_glop_pending(struct gfs2_inode > >

Re: [Intel-gfx] [RFC][PATCH] wake_up_var() memory ordering

On Tue, Jun 25, 2019 at 02:12:22PM +0200, Andreas Gruenbacher wrote: > > Only if we do as David suggested and make clean_and_wake_up_bit() > > provide the RELEASE barrier. > > (It's clear_and_wake_up_bit, not clean_and_wake_up_bit.) Yes, typing hard. > > That is, currently

[Intel-gfx] [RFC][PATCH] wake_up_var() memory ordering

Hi all, I tried using wake_up_var() today and accidentally noticed that it didn't imply an smp_mb() and specifically requires it through wake_up_bit() / waitqueue_active(). Now, wake_up_bit() doesn't imply the barrier because it is assumed to be used with the atomic bitops API which either

Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3

On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote: > Fix this by creating a prinkt_safe_up() which calls wake_up_process > outside of the spinlock. This isn't correct in full generality, but > good enough for console_lock: > > - console_lock doesn't use interruptible or killable or

Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3

On Thu, May 09, 2019 at 03:06:09PM +0200, Daniel Vetter wrote: > On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote: > > On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote: > > > Fix this by creating a prinkt_safe_up() which calls wake_up_process > > &

Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2

On Thu, May 09, 2019 at 11:32:57AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2019-05-06 08:45:53) > > +/** > > + * printk_safe_up - release the semaphore in console_unlock > > + * @sem: the semaphore to release > > + * > > + * Release the semaphore. Unlike mutexes, up() may be called

Re: [Intel-gfx] [patch V2 28/29] stacktrace: Provide common infrastructure

On Fri, Apr 19, 2019 at 10:32:30AM +0200, Thomas Gleixner wrote: > On Fri, 19 Apr 2019, Peter Zijlstra wrote: > > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote: > > > > > +typedef bool (*stack_trace_consume_fn)(void *co

Re: [Intel-gfx] [patch V2 28/29] stacktrace: Provide common infrastructure

On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote: > +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr, > + bool reliable); > +void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie, > +

Re: [Intel-gfx] [patch V2 28/29] stacktrace: Provide common infrastructure

On Thu, Apr 18, 2019 at 05:42:55PM +0200, Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Josh Poimboeuf wrote: > > Another idea I had (but never got a chance to work on) was to extend the > > x86 unwind interface to all arches. So instead of the callbacks, each > > arch would implement something

Re: [Intel-gfx] [patch V2 19/29] lockdep: Simplify stack trace handling

On Thu, Apr 18, 2019 at 10:41:38AM +0200, Thomas Gleixner wrote: > Replace the indirection through struct stack_trace by using the storage > array based interfaces and storing the information is a small lockdep > specific data structure. > Acked-by: Peter Zij

Re: [Intel-gfx] [patch V2 18/29] lockdep: Move stack trace logic into check_prev_add()

On Thu, Apr 18, 2019 at 10:41:37AM +0200, Thomas Gleixner wrote: > There is only one caller of check_prev_add() which hands in a zeroed struct > stack trace and a function pointer to save_stack(). Inside check_prev_add() > the stack_trace struct is checked for being empty, which is always > true.

Re: [Intel-gfx] [patch V3 18/29] lockdep: Remove save argument from check_prev_add()

On Thu, Apr 25, 2019 at 11:45:11AM +0200, Thomas Gleixner wrote: > There is only one caller which hands in save_trace as function pointer. > > Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 3/4] kernel.h: Add non_block_start/end()

tually squash in the fixup I had lying > > around :-/ > > > > v4: Pick the suggestion from Andrew Morton to give non_block_start/end > > some good kerneldoc comments. I added that other blocking calls like > > wait_event pose similar issues, since that's the other exam

  1   2   >