Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-26 Thread Stephen Bates
> We have atomic_long_t for that. Please use it instead. It will be > 64-bit on 64-bit archs, and 32-bit on 32-bit archs, which seems to > fit your purpose here. Thanks you Mathieu! Yes atomic_long_t looks perfect for this and addresses Daniel’s concerns for 32 bit systems. I’ll prepare a v2

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-26 Thread Stephen Bates
> We have atomic_long_t for that. Please use it instead. It will be > 64-bit on 64-bit archs, and 32-bit on 32-bit archs, which seems to > fit your purpose here. Thanks you Mathieu! Yes atomic_long_t looks perfect for this and addresses Daniel’s concerns for 32 bit systems. I’ll prepare a v2

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Mathieu Desnoyers
- On Oct 26, 2017, at 12:20 AM, Stephen Bates sba...@raithlin.com wrote: >> I found that genalloc is very slow for large chunk sizes because >> bitmap_find_next_zero_area has to grind through that entire bitmap. >> Hence, I recommend avoiding genalloc for large chunk sizes. > > Thanks for

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Mathieu Desnoyers
- On Oct 26, 2017, at 12:20 AM, Stephen Bates sba...@raithlin.com wrote: >> I found that genalloc is very slow for large chunk sizes because >> bitmap_find_next_zero_area has to grind through that entire bitmap. >> Hence, I recommend avoiding genalloc for large chunk sizes. > > Thanks for

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Stephen Bates
> I found that genalloc is very slow for large chunk sizes because > bitmap_find_next_zero_area has to grind through that entire bitmap. > Hence, I recommend avoiding genalloc for large chunk sizes. Thanks for the feedback Daniel! We have been doing 16GiB without any noticeable issues. > I'm

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Stephen Bates
> I found that genalloc is very slow for large chunk sizes because > bitmap_find_next_zero_area has to grind through that entire bitmap. > Hence, I recommend avoiding genalloc for large chunk sizes. Thanks for the feedback Daniel! We have been doing 16GiB without any noticeable issues. > I'm

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Logan Gunthorpe
On 25/10/17 11:55 AM, Daniel Mentz wrote: avail is defined as size_t (32 bit). Aren't you going to overflow that variable? I think the point is to get support for 64-bit systems (ie. ARM64 and x64. We're working with large PCI BARs and need some way to allocate memory from them. You aren't

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Logan Gunthorpe
On 25/10/17 11:55 AM, Daniel Mentz wrote: avail is defined as size_t (32 bit). Aren't you going to overflow that variable? I think the point is to get support for 64-bit systems (ie. ARM64 and x64. We're working with large PCI BARs and need some way to allocate memory from them. You aren't

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Daniel Mentz
I found that genalloc is very slow for large chunk sizes because bitmap_find_next_zero_area has to grind through that entire bitmap. Hence, I recommend avoiding genalloc for large chunk sizes. I'm thinking how this would behave on a 32 bit ARM platform On Wed, Oct 25, 2017 at 8:32 AM,

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Daniel Mentz
I found that genalloc is very slow for large chunk sizes because bitmap_find_next_zero_area has to grind through that entire bitmap. Hence, I recommend avoiding genalloc for large chunk sizes. I'm thinking how this would behave on a 32 bit ARM platform On Wed, Oct 25, 2017 at 8:32 AM, wrote: >

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Logan Gunthorpe
On 25/10/17 09:32 AM, sba...@raithlin.com wrote: From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread Logan Gunthorpe
On 25/10/17 09:32 AM, sba...@raithlin.com wrote: From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in atomic64 operations

[PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread sbates
From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in atomic64 operations on platforms that do not support

[PATCH] genalloc: Make the avail variable an atomic64_t

2017-10-25 Thread sbates
From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in atomic64 operations on platforms that do not support them natively.