On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
That's exactly what you need to explain in the patch or the commit
message. In fact you still haven't explained it fully. Why do we
need a second attempt without the GFP_NOFAIL? How does it
On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
That's exactly what you need to explain in the patch or the commit
message. In fact you still haven't explained it fully. Why do we
need a second attempt without the GFP_NOFAIL? How does it
On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
> On Wed, 30 May 2018, Herbert Xu wrote:
>
> > It doesn't explain it at all. In fact I don't see why we neeed
> > three attempts, just do the GFP_NOFAIL as the second and final step.
>
> Second attempt is reduced size only as we
On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
> On Wed, 30 May 2018, Herbert Xu wrote:
>
> > It doesn't explain it at all. In fact I don't see why we neeed
> > three attempts, just do the GFP_NOFAIL as the second and final step.
>
> Second attempt is reduced size only as we
On Wed, 30 May 2018, Herbert Xu wrote:
Well I think we should respect min_size. rhashtable users may
fail at insertion time if the table is too small.
I'm fine either way.
On Wed, 30 May 2018, Herbert Xu wrote:
Well I think we should respect min_size. rhashtable users may
fail at insertion time if the table is too small.
I'm fine either way.
On Wed, 30 May 2018, Herbert Xu wrote:
It doesn't explain it at all. In fact I don't see why we neeed
three attempts, just do the GFP_NOFAIL as the second and final step.
Second attempt is reduced size only as we don't want to GFP_NOFAIL
if we can avoid it helping the allocator. We go from
On Wed, 30 May 2018, Herbert Xu wrote:
It doesn't explain it at all. In fact I don't see why we neeed
three attempts, just do the GFP_NOFAIL as the second and final step.
Second attempt is reduced size only as we don't want to GFP_NOFAIL
if we can avoid it helping the allocator. We go from
On Tue, May 29, 2018 at 10:55:13AM -0700, Davidlohr Bueso wrote:
> On Wed, 30 May 2018, Herbert Xu wrote:
>
> > On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
> > >
> > > For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
> > > such that we have a single
On Tue, May 29, 2018 at 10:55:13AM -0700, Davidlohr Bueso wrote:
> On Wed, 30 May 2018, Herbert Xu wrote:
>
> > On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
> > >
> > > For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
> > > such that we have a single
On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
such that we have a single fallback.
Where did he suggest that?
https://lkml.org/lkml/2018/5/24/1265
On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
such that we have a single fallback.
Where did he suggest that?
https://lkml.org/lkml/2018/5/24/1265
On Tue, May 29, 2018 at 10:03:38AM -0700, Davidlohr Bueso wrote:
> On Mon, 28 May 2018, Herbert Xu wrote:
> > > + /*
> > > + * This is api initialization and thus we need to guarantee the
> > > + * initial rhashtable allocation. Upon failure, retry with a
> > > + * smallest possible size,
On Tue, May 29, 2018 at 10:03:38AM -0700, Davidlohr Bueso wrote:
> On Mon, 28 May 2018, Herbert Xu wrote:
> > > + /*
> > > + * This is api initialization and thus we need to guarantee the
> > > + * initial rhashtable allocation. Upon failure, retry with a
> > > + * smallest possible size,
On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
>
> For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
> such that we have a single fallback.
Where did he suggest that?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
>
> For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
> such that we have a single fallback.
Where did he suggest that?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Mon, 28 May 2018, Herbert Xu wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size, otherwise we exhaust our options with
+* __GFP_NOFAIL.
+
On Mon, 28 May 2018, Herbert Xu wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size, otherwise we exhaust our options with
+* __GFP_NOFAIL.
+
On Mon, 28 May 2018, Herbert Xu wrote:
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size,
On Mon, 28 May 2018, Herbert Xu wrote:
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size,
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
>
> + /*
> + * This is api initialization and thus we need to guarantee the
> + * initial rhashtable allocation. Upon failure, retry with a
> + * smallest possible size, otherwise we exhaust our options with
> +
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
>
> + /*
> + * This is api initialization and thus we need to guarantee the
> + * initial rhashtable allocation. Upon failure, retry with a
> + * smallest possible size, otherwise we exhaust our options with
> +
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
>
> -static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
> -size_t nbuckets,
> -gfp_t gfp)
> +static struct bucket_table
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
>
> -static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
> -size_t nbuckets,
> -gfp_t gfp)
> +static struct bucket_table
On Thu, 24 May 2018, Davidlohr Bueso wrote:
size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
+ if (retry) {
+ gfp |= __GFP_NOFAIL;
+ tbl = kzalloc(size, gfp);
+ } /* fall-through */
+
if (gfp != GFP_KERNEL)
tbl =
On Thu, 24 May 2018, Davidlohr Bueso wrote:
size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
+ if (retry) {
+ gfp |= __GFP_NOFAIL;
+ tbl = kzalloc(size, gfp);
+ } /* fall-through */
+
if (gfp != GFP_KERNEL)
tbl =
rhashtable_init() may fail due to -ENOMEM, thus making the
entire api unusable. This patch removes this scenario,
however unlikely. In order to guarantee memory allocation,
this patch refactors bucket_table_alloc() to add a 'retry'
parameter which always ends up doing GFP_KERNEL|__GFP_NOFAIL
for
rhashtable_init() may fail due to -ENOMEM, thus making the
entire api unusable. This patch removes this scenario,
however unlikely. In order to guarantee memory allocation,
this patch refactors bucket_table_alloc() to add a 'retry'
parameter which always ends up doing GFP_KERNEL|__GFP_NOFAIL
for
28 matches
Mail list logo
