This patch converts pages_nr per-pool counter to atomic64_t.
Signed-off-by: Vitaly Wool <[email protected]>
---
mm/z3fold.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 8f9e89c..4d02280 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -80,7 +80,7 @@ struct z3fold_pool {
struct list_head unbuddied[NCHUNKS];
struct list_head buddied;
struct list_head lru;
- u64 pages_nr;
+ atomic64_t pages_nr;
const struct z3fold_ops *ops;
struct zpool *zpool;
const struct zpool_ops *zpool_ops;
@@ -234,7 +234,7 @@ static struct z3fold_pool *z3fold_create_pool(gfp_t gfp,
INIT_LIST_HEAD(&pool->unbuddied[i]);
INIT_LIST_HEAD(&pool->buddied);
INIT_LIST_HEAD(&pool->lru);
- pool->pages_nr = 0;
+ atomic64_set(&pool->pages_nr, 0);
pool->ops = ops;
return pool;
}
@@ -346,7 +346,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
if (!page)
return -ENOMEM;
spin_lock(&pool->lock);
- pool->pages_nr++;
+ atomic64_inc(&pool->pages_nr);
zhdr = init_z3fold_page(page);
if (bud == HEADLESS) {
@@ -439,10 +439,9 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
return;
}
- if (bud != HEADLESS) {
- /* Remove from existing buddy list */
+ /* Remove from existing buddy list */
+ if (bud != HEADLESS)
list_del(&zhdr->buddy);
- }
if (bud == HEADLESS ||
(zhdr->first_chunks == 0 && zhdr->middle_chunks == 0 &&
@@ -451,7 +451,7 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
list_del(&page->lru);
clear_bit(PAGE_HEADLESS, &page->private);
free_z3fold_page(zhdr);
- pool->pages_nr--;
+ atomic64_dec(&pool->pages_nr);
} else {
z3fold_compact_page(zhdr);
/* Add to the unbuddied list */
@@ -569,7 +569,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
*/
clear_bit(PAGE_HEADLESS, &page->private);
free_z3fold_page(zhdr);
- pool->pages_nr--;
+ atomic64_dec(&pool->pages_nr);
spin_unlock(&pool->lock);
return 0;
} else if (!test_bit(PAGE_HEADLESS, &page->private)) {
@@ -672,12 +672,11 @@ static void z3fold_unmap(struct z3fold_pool *pool, unsigned long handle)
* z3fold_get_pool_size() - gets the z3fold pool size in pages
* @pool: pool whose size is being queried
*
- * Returns: size in pages of the given pool. The pool lock need not be
- * taken to access pages_nr.
+ * Returns: size in pages of the given pool.
*/
static u64 z3fold_get_pool_size(struct z3fold_pool *pool)
{
- return pool->pages_nr;
+ return atomic64_read(&pool->pages_nr);
}
/*****************
--
2.4.2
On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool <[email protected]> wrote:
> This patch converts pages_nr per-pool counter to atomic64_t.
Which is slower.
Presumably there is a reason for making this change. This reason
should be described in the changelog.
On Thu, Nov 3, 2016 at 10:14 PM, Andrew Morton
<[email protected]> wrote:
> On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool <[email protected]> wrote:
>
>> This patch converts pages_nr per-pool counter to atomic64_t.
>
> Which is slower.
>
> Presumably there is a reason for making this change. This reason
> should be described in the changelog.
The reason [which I thought was somewhat obvious :) ] is that there
won't be a need to take a per-pool lock to read or modify that
counter.
Best regards,
Vitaly
On Thu, 3 Nov 2016 22:24:07 +0100 Vitaly Wool <[email protected]> wrote:
> On Thu, Nov 3, 2016 at 10:14 PM, Andrew Morton
> <[email protected]> wrote:
> > On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool <[email protected]> wrote:
> >
> >> This patch converts pages_nr per-pool counter to atomic64_t.
> >
> > Which is slower.
> >
> > Presumably there is a reason for making this change. This reason
> > should be described in the changelog.
>
> The reason [which I thought was somewhat obvious :) ] is that there
> won't be a need to take a per-pool lock to read or modify that
> counter.
But the patch didn't change the locking. And as far as I can tell,
neither does "z3fold: extend compaction function".
On Thu, Nov 3, 2016 at 11:17 PM, Andrew Morton
<[email protected]> wrote:
> On Thu, 3 Nov 2016 22:24:07 +0100 Vitaly Wool <[email protected]> wrote:
>
>> On Thu, Nov 3, 2016 at 10:14 PM, Andrew Morton
>> <[email protected]> wrote:
>> > On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool <[email protected]> wrote:
>> >
>> >> This patch converts pages_nr per-pool counter to atomic64_t.
>> >
>> > Which is slower.
>> >
>> > Presumably there is a reason for making this change. This reason
>> > should be described in the changelog.
>>
>> The reason [which I thought was somewhat obvious :) ] is that there
>> won't be a need to take a per-pool lock to read or modify that
>> counter.
>
> But the patch didn't change the locking. And as far as I can tell,
> neither does "z3fold: extend compaction function".
Right. I'll come up with the locking rework shortly, but it will be a
RFC so I wanted to send it separately.
~vitaly
On Fri, Nov 4, 2016 at 3:27 AM, Vitaly Wool <[email protected]> wrote:
> On Thu, Nov 3, 2016 at 11:17 PM, Andrew Morton
> <[email protected]> wrote:
>> On Thu, 3 Nov 2016 22:24:07 +0100 Vitaly Wool <[email protected]> wrote:
>>
>>> On Thu, Nov 3, 2016 at 10:14 PM, Andrew Morton
>>> <[email protected]> wrote:
>>> > On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool <[email protected]> wrote:
>>> >
>>> >> This patch converts pages_nr per-pool counter to atomic64_t.
>>> >
>>> > Which is slower.
>>> >
>>> > Presumably there is a reason for making this change. This reason
>>> > should be described in the changelog.
>>>
>>> The reason [which I thought was somewhat obvious :) ] is that there
>>> won't be a need to take a per-pool lock to read or modify that
>>> counter.
>>
>> But the patch didn't change the locking. And as far as I can tell,
>> neither does "z3fold: extend compaction function".
>
> Right. I'll come up with the locking rework shortly, but it will be a
> RFC so I wanted to send it separately.
this is still in mmotm, and it seems the later patches rely on it, so
while i agree that the changelog should be clearer about why it's
needed, the change itself looks ok.
Acked-by: Dan Streetman <[email protected]>
>
> ~vitaly