Herbert Xu <herb...@gondor.apana.org.au> wrote: > This patch adds code that handles GFP_ATOMIC kmalloc failure on > insertion. As we cannot use vmalloc, we solve it by making our > hash table nested. That is, we allocate single pages at each level > and reach our desired table size by nesting them. > > When a nested table is created, only a single page is allocated > at the top-level. Lower levels are allocated on demand during > insertion. Therefore for each insertion to succeed, only two > (non-consecutive) pages are needed. > > After a nested table is created, a rehash will be scheduled in > order to switch to a vmalloced table as soon as possible. Also, > the rehash code will never rehash into a nested table. If we > detect a nested table during a rehash, the rehash will be aborted > and a new rehash will be scheduled.
Ok, but why? It seems to add a whole lot of complexity... What users can't handle the insert failure case until resize has completed? Would relaxing the max chain length (until rehash is done) be an alternative?
