Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1283123

RE: rhashtable: ENOMEM errors when hit with a flood of insertions

From David Laight <David.Laight@ACULAB.COM>
Newsgroups linux.kernel
Subject RE: rhashtable: ENOMEM errors when hit with a flood of insertions
Date 2015-12-03 16:20 +0100
Message-ID <qBDPQ-6Rh-25@gated-at.bofh.it> (permalink)
References <qwXvP-1JB-15@gated-at.bofh.it> <qAt6b-1Ny-17@gated-at.bofh.it> <qAtIR-2gq-1@gated-at.bofh.it> <qAtIR-2gq-15@gated-at.bofh.it> <qBBEn-58q-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


From: Herbert Xu
> Sent: 03 December 2015 12:51
> On Mon, Nov 30, 2015 at 06:18:59PM +0800, Herbert Xu wrote:
> >
> > OK that's better.  I think I see the problem.  The test in
> > rhashtable_insert_rehash is racy and if two threads both try
> > to grow the table one of them may be tricked into doing a rehash
> > instead.
> >
> > I'm working on a fix.
> 
> While the EBUSY errors are gone for me, I can still see plenty
> of ENOMEM errors.  In fact it turns out that the reason is quite
> understandable.  When you pound the rhashtable hard so that it
> doesn't actually get a chance to grow the table in process context,
> then the table will only grow with GFP_ATOMIC allocations.
> 
> For me this starts failing regularly at around 2^19 entries, which
> requires about 1024 contiguous pages if I'm not mistaken.

ISTM that you should always let the insert succeed - even if it makes
the average/maximum chain length increase beyond some limit.
Any limit on the number of hashed items should have been done earlier
by the calling code.
The slight performance decrease caused by scanning longer chains
is almost certainly more 'user friendly' than an error return.

Hoping to get 1024+ contiguous VA pages does seem over-optimistic.

With a 2-level lookup you could make all the 2nd level tables
a fixed size (maybe 4 or 8 pages?) and extend the first level
table as needed.

	David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

rhashtable: ENOMEM errors when hit with a flood of insertions Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-03 14:00 +0100
  RE: rhashtable: ENOMEM errors when hit with a flood of insertions David Laight <David.Laight@ACULAB.COM> - 2015-12-03 16:20 +0100
  Re: rhashtable: ENOMEM errors when hit with a flood of insertions Eric Dumazet <eric.dumazet@gmail.com> - 2015-12-03 17:10 +0100
    Re: rhashtable: ENOMEM errors when hit with a flood of insertions Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-04 01:10 +0100
    rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-04 15:50 +0100
      Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Eric Dumazet <eric.dumazet@gmail.com> - 2015-12-04 18:50 +0100
        Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Phil Sutter <phil@nwl.cc> - 2015-12-04 19:20 +0100
          Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-05 08:10 +0100
            Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Thomas Graf <tgraf@suug.ch> - 2015-12-07 16:40 +0100
              Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation David Miller <davem@davemloft.net> - 2015-12-07 20:40 +0100
                Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Thomas Graf <tgraf@suug.ch> - 2015-12-09 03:20 +0100
                Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-09 03:30 +0100
                Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-09 03:40 +0100
                Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Thomas Graf <tgraf@suug.ch> - 2015-12-09 03:50 +0100
                Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Thomas Graf <tgraf@suug.ch> - 2015-12-09 03:40 +0100
      Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation David Miller <davem@davemloft.net> - 2015-12-04 23:00 +0100
        Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-05 08:10 +0100
          Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation David Miller <davem@davemloft.net> - 2015-12-06 04:50 +0100

csiph-web