| Message ID | 1424964034.5565.162.camel@edumazet-glaptop2.roam.corp.google.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Eric Dumazet Sent: 26 February 2015 15:21 > If a hash table has 128 slots and 16384 elems, expand to 256 slots > takes more than one second. For larger sets, a soft lockup is detected. What on earth is it doing? Presumably something to do with the rcu actions needed to allow lockless lookup during resize. There has to be a better solution? Perhaps even two sets of chain pointers down the hash lists. Then the old hash table can be kept completely valid while the whole 'unzip' action is done. David
On 26.02, David Laight wrote: > From: Eric Dumazet > Sent: 26 February 2015 15:21 > > If a hash table has 128 slots and 16384 elems, expand to 256 slots > > takes more than one second. For larger sets, a soft lockup is detected. > > What on earth is it doing? > Presumably something to do with the rcu actions needed to allow > lockless lookup during resize. > > There has to be a better solution? > Perhaps even two sets of chain pointers down the hash lists. > Then the old hash table can be kept completely valid while the > whole 'unzip' action is done. One of the main points of rhashtable is that you don't need those. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/26/2015 04:20 PM, Eric Dumazet wrote: > From: Eric Dumazet <edumazet@google.com> > > If a hash table has 128 slots and 16384 elems, expand to 256 slots > takes more than one second. For larger sets, a soft lockup is detected. > > Holding cpu for that long, even in a work queue is a show stopper > for non preemptable kernels. > > cond_resched() at strategic points to allow process scheduler > to reschedule us. > > Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Patrick McHardy [mailto:kaber@trash.net] > On 26.02, David Laight wrote: > > From: Eric Dumazet > > Sent: 26 February 2015 15:21 > > > If a hash table has 128 slots and 16384 elems, expand to 256 slots > > > takes more than one second. For larger sets, a soft lockup is detected. > > > > What on earth is it doing? > > Presumably something to do with the rcu actions needed to allow > > lockless lookup during resize. > > > > There has to be a better solution? > > Perhaps even two sets of chain pointers down the hash lists. > > Then the old hash table can be kept completely valid while the > > whole 'unzip' action is done. > > One of the main points of rhashtable is that you don't need those. Would it be possible to keep the hash chains sorted into 'raw hash' order? I think that would mean the 'unzip' only had to change a single linkage. David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Thu, 26 Feb 2015 07:20:34 -0800 > From: Eric Dumazet <edumazet@google.com> > > If a hash table has 128 slots and 16384 elems, expand to 256 slots > takes more than one second. For larger sets, a soft lockup is detected. > > Holding cpu for that long, even in a work queue is a show stopper > for non preemptable kernels. > > cond_resched() at strategic points to allow process scheduler > to reschedule us. > > Signed-off-by: Eric Dumazet <edumazet@google.com> Applied, thanks Eric. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/lib/rhashtable.c b/lib/rhashtable.c index e3a04e4b3ec5..f3073fc600ed 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -17,6 +17,7 @@ #include <linux/kernel.h> #include <linux/init.h> #include <linux/log2.h> +#include <linux/sched.h> #include <linux/slab.h> #include <linux/vmalloc.h> #include <linux/mm.h> @@ -414,6 +415,7 @@ int rhashtable_expand(struct rhashtable *ht) } } unlock_buckets(new_tbl, old_tbl, new_hash); + cond_resched(); } /* Unzip interleaved hash chains */ @@ -437,6 +439,7 @@ int rhashtable_expand(struct rhashtable *ht) complete = false; unlock_buckets(new_tbl, old_tbl, old_hash); + cond_resched(); } } @@ -495,6 +498,7 @@ int rhashtable_shrink(struct rhashtable *ht) tbl->buckets[new_hash + new_tbl->size]); unlock_buckets(new_tbl, tbl, new_hash); + cond_resched(); } /* Publish the new, valid hash table */