On Wed, Feb 17, 2016 at 01:45:35PM -0500, Waiman Long wrote:
> The original code has one global lock and one single list that covers all
> the inodes in the filesystem. This patch essentially breaks it up into
> multiple smaller lists with one lock for each. So the lock hold time should
> have been
On 02/17/2016 01:22 PM, Peter Zijlstra wrote:
On Wed, Feb 17, 2016 at 12:41:53PM -0500, Waiman Long wrote:
On 02/17/2016 12:18 PM, Peter Zijlstra wrote:
On Wed, Feb 17, 2016 at 12:12:57PM -0500, Waiman Long wrote:
On 02/17/2016 11:27 AM, Christoph Lameter wrote:
On Wed, 17 Feb 2016, Waiman Lo
On Wed, Feb 17, 2016 at 12:41:53PM -0500, Waiman Long wrote:
> On 02/17/2016 12:18 PM, Peter Zijlstra wrote:
> >On Wed, Feb 17, 2016 at 12:12:57PM -0500, Waiman Long wrote:
> >>On 02/17/2016 11:27 AM, Christoph Lameter wrote:
> >>>On Wed, 17 Feb 2016, Waiman Long wrote:
> >>>
> I know we can us
On 02/17/2016 12:18 PM, Peter Zijlstra wrote:
On Wed, Feb 17, 2016 at 12:12:57PM -0500, Waiman Long wrote:
On 02/17/2016 11:27 AM, Christoph Lameter wrote:
On Wed, 17 Feb 2016, Waiman Long wrote:
I know we can use RCU for singly linked list, but I don't think we can use
that for doubly linked
On Wed, Feb 17, 2016 at 12:12:57PM -0500, Waiman Long wrote:
> On 02/17/2016 11:27 AM, Christoph Lameter wrote:
> >On Wed, 17 Feb 2016, Waiman Long wrote:
> >
> >>I know we can use RCU for singly linked list, but I don't think we can use
> >>that for doubly linked list as there is no easy way to ma
On 02/17/2016 11:27 AM, Christoph Lameter wrote:
On Wed, 17 Feb 2016, Waiman Long wrote:
I know we can use RCU for singly linked list, but I don't think we can use
that for doubly linked list as there is no easy way to make atomic changes to
both prev and next pointers simultaneously unless you
On Wed, 17 Feb 2016, Waiman Long wrote:
> I know we can use RCU for singly linked list, but I don't think we can use
> that for doubly linked list as there is no easy way to make atomic changes to
> both prev and next pointers simultaneously unless you are taking about 16b
> cmpxchg which is only
On Wed, Feb 17, 2016 at 11:16:10AM -0500, Waiman Long wrote:
> >So why not use RCU for the list iteration and avoid potentially large
> >lock hold times?
> >
>
> I know we can use RCU for singly linked list, but I don't think we can use
> that for doubly linked list as there is no easy way to make
On 02/17/2016 06:05 AM, Peter Zijlstra wrote:
On Wed, Feb 17, 2016 at 12:00:40PM +0100, Peter Zijlstra wrote:
On Wed, Feb 17, 2016 at 08:53:18PM +1100, Dave Chinner wrote:
+/**
+ * for_all_percpu_list_entries - iterate over all the per-cpu list with locking
But the locking is 'pointless'. You
On Wed, Feb 17, 2016 at 10:56:10AM -0500, Waiman Long wrote:
> >>+/**
> >>+ * for_all_percpu_list_entries - iterate over all the per-cpu list with
> >>locking
> >>+ * @pos: the type * to use as a loop cursor for the current .
> >>+ * @next: an internal type * variable pointing to the next entry
On 02/17/2016 04:53 AM, Dave Chinner wrote:
On Tue, Feb 16, 2016 at 08:31:19PM -0500, Waiman Long wrote:
Linked list is used everywhere in the Linux kernel. However, if many
threads are trying to add or delete entries into the same linked list,
it can create a performance bottleneck.
This patch
On Tue, 16 Feb 2016, Waiman Long wrote:
> List entry insertion is strictly per cpu. List deletion, however, can
> happen in a cpu other than the one that did the insertion. So we still
> need lock to protect the list. Because of that, there may still be
> a small amount of contention when deletion
On Wed, Feb 17, 2016 at 12:26:54PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 10:10:02PM +1100, Dave Chinner wrote:
> > On Wed, Feb 17, 2016 at 12:00:40PM +0100, Peter Zijlstra wrote:
>
> > > Yeah, that is pretty terrible. Maybe a visitor interface is advisable?
> > >
> > > visit_perc
On Wed, Feb 17, 2016 at 10:10:02PM +1100, Dave Chinner wrote:
> On Wed, Feb 17, 2016 at 12:00:40PM +0100, Peter Zijlstra wrote:
> > Yeah, that is pretty terrible. Maybe a visitor interface is advisable?
> >
> > visit_percpu_list_entries(struct percpu_list *head, void (*visitor)(struct
> > list_h
On Wed, Feb 17, 2016 at 12:00:40PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 08:53:18PM +1100, Dave Chinner wrote:
> > > +/**
> > > + * for_all_percpu_list_entries - iterate over all the per-cpu list with
> > > locking
> > > + * @pos: the type * to use as a loop cursor for the current
On Wed, Feb 17, 2016 at 12:00:40PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 08:53:18PM +1100, Dave Chinner wrote:
> > > +/**
> > > + * for_all_percpu_list_entries - iterate over all the per-cpu list with
> > > locking
But the locking is 'pointless'. You only lock one per-cpu sublist
On Wed, Feb 17, 2016 at 08:53:18PM +1100, Dave Chinner wrote:
> > +/**
> > + * for_all_percpu_list_entries - iterate over all the per-cpu list with
> > locking
> > + * @pos: the type * to use as a loop cursor for the current .
> > + * @next: an internal type * variable pointing to the next entr
On Tue, Feb 16, 2016 at 08:31:19PM -0500, Waiman Long wrote:
> Linked list is used everywhere in the Linux kernel. However, if many
> threads are trying to add or delete entries into the same linked list,
> it can create a performance bottleneck.
>
> This patch introduces a new per-cpu list subyst
Linked list is used everywhere in the Linux kernel. However, if many
threads are trying to add or delete entries into the same linked list,
it can create a performance bottleneck.
This patch introduces a new per-cpu list subystem with associated
per-cpu locks for protecting each of the lists indiv
19 matches
Mail list logo
