search for: cachelines

On Fri, Apr 18, 2014 at 01:32:47PM -0400, Waiman Long wrote: > On 04/18/2014 04:15 AM, Peter Zijlstra wrote: > >On Thu, Apr 17, 2014 at 05:28:17PM -0400, Waiman Long wrote: > >>On 04/17/2014 11:49 AM, Peter Zijlstra wrote: > >>>On Thu, Apr 17, 2014 at 11:03:56AM -0400, Waiman Long wrote: > >>>>@@ -192,36 +220,25 @@ void queue_spin_lock_slowpath(struct

On Fri, Apr 18, 2014 at 01:32:47PM -0400, Waiman Long wrote: > On 04/18/2014 04:15 AM, Peter Zijlstra wrote: > >On Thu, Apr 17, 2014 at 05:28:17PM -0400, Waiman Long wrote: > >>On 04/17/2014 11:49 AM, Peter Zijlstra wrote: > >>>On Thu, Apr 17, 2014 at 11:03:56AM -0400, Waiman Long wrote: > >>>>@@ -192,36 +220,25 @@ void queue_spin_lock_slowpath(struct

...ese threads need to communicate some set of values. When they write their values, they can use their instance number to index into an array of struct.V's. But, say two threads i and i+1 are both trying to write to the array. I would like to ensure that array[i] and array[i+1] lay in different cachelines. The only way to guarantee that is if each /element/ of the array is cacheline aligned. In other words, I am not trying to align the global variable (the array) to a cacheline, rather its elements. I accomplish this by first making an assumption about cacheline size, and then adding a char[] pad...

On Thu, Apr 17, 2014 at 05:28:17PM -0400, Waiman Long wrote: > On 04/17/2014 11:49 AM, Peter Zijlstra wrote: > >On Thu, Apr 17, 2014 at 11:03:56AM -0400, Waiman Long wrote: > >>@@ -192,36 +220,25 @@ void queue_spin_lock_slowpath(struct qspinlock *lock, u32 val) > >> node->next = NULL; > >> > >> /* > >>+ * We touched a (possibly) cold

On Thu, Apr 17, 2014 at 05:28:17PM -0400, Waiman Long wrote: > On 04/17/2014 11:49 AM, Peter Zijlstra wrote: > >On Thu, Apr 17, 2014 at 11:03:56AM -0400, Waiman Long wrote: > >>@@ -192,36 +220,25 @@ void queue_spin_lock_slowpath(struct qspinlock *lock, u32 val) > >> node->next = NULL; > >> > >> /* > >>+ * We touched a (possibly) cold

Chris, On Thu, May 7, 2009 at 7:20 PM, Chris Lattner <clattner at apple.com> wrote: > nd what you're saying. LLVM can and does already > express this, just in a different form. Why does this need to be in > the type? I misunderstood your earlier email. Now I understand. Setting alignment on a global variable will work for many of my needs. However, say I need to construct

Hello Since lot of release (at least since 4.19), I hit the following error message: DMA-API: cacheline tracking ENOMEM, dma-debug disabled After hitting that, I try to check who is creating so many DMA mapping and see: cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c 6 ahci 257 e1000e 6 ehci-pci 5891 nouveau 24 uhci_hcd Does nouveau having

On May 7, 2009, at 5:58 PM, Nick Johnson wrote: > Chris, > > On Thu, May 7, 2009 at 7:20 PM, Chris Lattner <clattner at apple.com> > wrote: >> nd what you're saying. LLVM can and does already >> express this, just in a different form. Why does this need to be in >> the type? > > I misunderstood your earlier email. Now I understand. Setting >

On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: > > Hello > > > > Since lot of release (at least since 4.19), I hit the following error message: > > DMA-API: cacheline tracking ENOMEM, dma-debug disabled > > > > After hitting that, I try to check who is creating so many DMA

2014-05-14 19:00+0200, Peter Zijlstra: > On Wed, May 14, 2014 at 06:51:24PM +0200, Radim Kr?m?? wrote: > > Ok. > > I've seen merit in pvqspinlock even with slightly slower first-waiter, > > so I would have happily sacrificed those horrible branches. > > (I prefer elegant to optimized code, but I can see why we want to be > > strictly better than ticketlock.)

2014-05-14 19:00+0200, Peter Zijlstra: > On Wed, May 14, 2014 at 06:51:24PM +0200, Radim Kr?m?? wrote: > > Ok. > > I've seen merit in pvqspinlock even with slightly slower first-waiter, > > so I would have happily sacrificed those horrible branches. > > (I prefer elegant to optimized code, but I can see why we want to be > > strictly better than ticketlock.)

2014-05-13 15:47-0400, Waiman Long: > On 05/12/2014 11:22 AM, Radim Kr?m?? wrote: > >I think there is an unwanted scenario on virtual machines: > >1) VCPU sets the pending bit and start spinning. > >2) Pending VCPU gets descheduled. > > - we have PLE and lock holder isn't running [1] > > - the hypervisor randomly preempts us > >3) Lock holder

2014-05-13 15:47-0400, Waiman Long: > On 05/12/2014 11:22 AM, Radim Kr?m?? wrote: > >I think there is an unwanted scenario on virtual machines: > >1) VCPU sets the pending bit and start spinning. > >2) Pending VCPU gets descheduled. > > - we have PLE and lock holder isn't running [1] > > - the hypervisor randomly preempts us > >3) Lock holder

On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: > > Hello > > > > Since lot of release (at least since 4.19), I hit the following error message: > > DMA-API: cacheline tracking ENOMEM, dma-debug disabled > > > > After hitting that, I try to check who is creating so many DMA

On Thu, 23 May 2019 18:22:06 +0200 Michael Mueller <mimu at linux.ibm.com> wrote: > From: Halil Pasic <pasic at linux.ibm.com> > > The flag AIRQ_IV_CACHELINE was recently added to airq_iv_create(). Let > us use it! We actually wanted the vector to span a cacheline all along. > > Signed-off-by: Halil Pasic <pasic at linux.ibm.com> > --- >

...ode llist; /* 0 8 */ smp_call_func_t func; /* 8 8 */ void * info; /* 16 8 */ unsigned int flags; /* 24 4 */ /* size: 32, cachelines: 1, members: 4 */ /* padding: 4 */ /* last cacheline: 32 bytes */ }; struct flush_tlb_info { struct mm_struct * mm; /* 0 8 */ long unsigned int start; /* 8 8 */ long unsigned int end;...

...ode llist; /* 0 8 */ smp_call_func_t func; /* 8 8 */ void * info; /* 16 8 */ unsigned int flags; /* 24 4 */ /* size: 32, cachelines: 1, members: 4 */ /* padding: 4 */ /* last cacheline: 32 bytes */ }; struct flush_tlb_info { struct mm_struct * mm; /* 0 8 */ long unsigned int start; /* 8 8 */ long unsigned int end;...

On Sun, Jun 15, 2014 at 02:47:00PM +0200, Peter Zijlstra wrote: > Because the qspinlock needs to touch a second cacheline; add a pending > bit and allow a single in-word spinner before we punt to the second > cacheline. Could you add this in the description please: And by second cacheline we mean the local 'node'. That is the: mcs_nodes[0] and mcs_nodes[idx] Perhaps it might be

On Sun, Jun 15, 2014 at 02:47:00PM +0200, Peter Zijlstra wrote: > Because the qspinlock needs to touch a second cacheline; add a pending > bit and allow a single in-word spinner before we punt to the second > cacheline. Could you add this in the description please: And by second cacheline we mean the local 'node'. That is the: mcs_nodes[0] and mcs_nodes[idx] Perhaps it might be

On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: > Hello > > Since lot of release (at least since 4.19), I hit the following error message: > DMA-API: cacheline tracking ENOMEM, dma-debug disabled > > After hitting that, I try to check who is creating so many DMA mapping and see: > cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c