Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1530765 > unrolled thread
| Started by | Vitaly Wool <vitalywool@gmail.com> |
|---|---|
| First post | 2016-11-26 20:20 +0100 |
| Last post | 2016-11-29 23:40 +0100 |
| Articles | 5 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH 0/2] z3fold fixes Vitaly Wool <vitalywool@gmail.com> - 2016-11-26 20:20 +0100
[PATCH 1/2] z3fold: fix header size related issues Vitaly Wool <vitalywool@gmail.com> - 2016-11-26 20:20 +0100
[PATCH 2/2] z3fold: fix locking issues Vitaly Wool <vitalywool@gmail.com> - 2016-11-26 20:30 +0100
Re: [PATCH 0/2] z3fold fixes Dan Streetman <ddstreet@ieee.org> - 2016-11-29 23:40 +0100
Re: [PATCH 0/2] z3fold fixes Andrew Morton <akpm@linux-foundation.org> - 2016-11-29 23:40 +0100
| From | Vitaly Wool <vitalywool@gmail.com> |
|---|---|
| Date | 2016-11-26 20:20 +0100 |
| Subject | [PATCH 0/2] z3fold fixes |
| Message-ID | <sHQFY-2gJ-7@gated-at.bofh.it> |
Here come 2 patches with z3fold fixes for chunks counting and locking. As commit 50a50d2 ("z3fold: don't fail kernel build is z3fold_header is too big") was NAK'ed [1], I would suggest that we removed that one and the next z3fold commit cc1e9c8 ("z3fold: discourage use of pages that weren't compacted") and applied the coming 2 instead.
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
[1] https://lkml.org/lkml/2016/11/25/595
[toc] | [next] | [standalone]
| From | Vitaly Wool <vitalywool@gmail.com> |
|---|---|
| Date | 2016-11-26 20:20 +0100 |
| Subject | [PATCH 1/2] z3fold: fix header size related issues |
| Message-ID | <sHQFY-2gJ-5@gated-at.bofh.it> |
| In reply to | #1530765 |
Currently the whole kernel build will be stopped if the size of struct
z3fold_header is greater than the size of one chunk, which is 64 bytes
by default. This patch instead defines the offset for z3fold objects
as the size of the z3fold header in chunks.
Fixed also are the calculation of num_free_chunks() and the address to
move the middle chunk to in case of in-page compaction in
z3fold_compact_page().
This patch is to be applied on top of commit 570931c ("z3fold: use
per-page spinlock"), substituting commit 50a50d2 ("z3fold: don't fail
kernel build is z3fold_header is too big").
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
---
mm/z3fold.c | 161 ++++++++++++++++++++++++++++++++----------------------------
1 file changed, 87 insertions(+), 74 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 7ad70fa..efbcfcc 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -34,29 +34,60 @@
/*****************
* Structures
*****************/
+struct z3fold_pool;
+struct z3fold_ops {
+ int (*evict)(struct z3fold_pool *pool, unsigned long handle);
+};
+
+enum buddy {
+ HEADLESS = 0,
+ FIRST,
+ MIDDLE,
+ LAST,
+ BUDDIES_MAX
+};
+
+/*
+ * struct z3fold_header - z3fold page metadata occupying the first chunk of each
+ * z3fold page, except for HEADLESS pages
+ * @buddy: links the z3fold page into the relevant list in the pool
+ * @page_lock: per-page lock
+ * @first_chunks: the size of the first buddy in chunks, 0 if free
+ * @middle_chunks: the size of the middle buddy in chunks, 0 if free
+ * @last_chunks: the size of the last buddy in chunks, 0 if free
+ * @first_num: the starting number (for the first handle)
+ */
+struct z3fold_header {
+ struct list_head buddy;
+ raw_spinlock_t page_lock;
+ unsigned short first_chunks;
+ unsigned short middle_chunks;
+ unsigned short last_chunks;
+ unsigned short start_middle;
+ unsigned short first_num:2;
+};
+
/*
* NCHUNKS_ORDER determines the internal allocation granularity, effectively
* adjusting internal fragmentation. It also determines the number of
* freelists maintained in each pool. NCHUNKS_ORDER of 6 means that the
- * allocation granularity will be in chunks of size PAGE_SIZE/64. As one chunk
- * in allocated page is occupied by z3fold header, NCHUNKS will be calculated
- * to 63 which shows the max number of free chunks in z3fold page, also there
- * will be 63 freelists per pool.
+ * allocation granularity will be in chunks of size PAGE_SIZE/64. Some chunks
+ * in the beginning of an allocated page are occupied by z3fold header, so
+ * NCHUNKS will be calculated to 63 (or 62 in case CONFIG_DEBUG_SPINLOCK=y),
+ * which shows the max number of free chunks in z3fold page, also there will
+ * be 63, or 62, respectively, freelists per pool.
*/
#define NCHUNKS_ORDER 6
#define CHUNK_SHIFT (PAGE_SHIFT - NCHUNKS_ORDER)
#define CHUNK_SIZE (1 << CHUNK_SHIFT)
-#define ZHDR_SIZE_ALIGNED CHUNK_SIZE
+#define ZHDR_SIZE_ALIGNED round_up(sizeof(struct z3fold_header), CHUNK_SIZE)
+#define ZHDR_CHUNKS (ZHDR_SIZE_ALIGNED >> CHUNK_SHIFT)
+#define TOTAL_CHUNKS (PAGE_SIZE >> CHUNK_SHIFT)
#define NCHUNKS ((PAGE_SIZE - ZHDR_SIZE_ALIGNED) >> CHUNK_SHIFT)
#define BUDDY_MASK (0x3)
-struct z3fold_pool;
-struct z3fold_ops {
- int (*evict)(struct z3fold_pool *pool, unsigned long handle);
-};
-
/**
* struct z3fold_pool - stores metadata for each z3fold pool
* @lock: protects all pool fields and first|last_chunk fields of any
@@ -86,33 +117,6 @@ struct z3fold_pool {
const struct zpool_ops *zpool_ops;
};
-enum buddy {
- HEADLESS = 0,
- FIRST,
- MIDDLE,
- LAST,
- BUDDIES_MAX
-};
-
-/*
- * struct z3fold_header - z3fold page metadata occupying the first chunk of each
- * z3fold page, except for HEADLESS pages
- * @buddy: links the z3fold page into the relevant list in the pool
- * @page_lock: per-page lock
- * @first_chunks: the size of the first buddy in chunks, 0 if free
- * @middle_chunks: the size of the middle buddy in chunks, 0 if free
- * @last_chunks: the size of the last buddy in chunks, 0 if free
- * @first_num: the starting number (for the first handle)
- */
-struct z3fold_header {
- struct list_head buddy;
- raw_spinlock_t page_lock;
- unsigned short first_chunks;
- unsigned short middle_chunks;
- unsigned short last_chunks;
- unsigned short start_middle;
- unsigned short first_num:2;
-};
/*
* Internal z3fold page flags
@@ -123,6 +127,7 @@ enum z3fold_page_flags {
MIDDLE_CHUNK_MAPPED,
};
+
/*****************
* Helpers
*****************/
@@ -220,9 +225,10 @@ static int num_free_chunks(struct z3fold_header *zhdr)
*/
if (zhdr->middle_chunks != 0) {
int nfree_before = zhdr->first_chunks ?
- 0 : zhdr->start_middle - 1;
+ 0 : zhdr->start_middle - ZHDR_CHUNKS;
int nfree_after = zhdr->last_chunks ?
- 0 : NCHUNKS - zhdr->start_middle - zhdr->middle_chunks;
+ 0 : TOTAL_CHUNKS -
+ (zhdr->start_middle + zhdr->middle_chunks);
nfree = max(nfree_before, nfree_after);
} else
nfree = NCHUNKS - zhdr->first_chunks - zhdr->last_chunks;
@@ -287,40 +293,47 @@ static int z3fold_compact_page(struct z3fold_header *zhdr)
int ret = 0;
if (test_bit(MIDDLE_CHUNK_MAPPED, &page->private))
+ goto out; /* can't move middle chunk, it's used */
+
+ if (zhdr->middle_chunks == 0)
+ goto out; /* nothing to compact */
+
+ if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
+ /* move to the beginning */
+ mchunk_memmove(zhdr, ZHDR_CHUNKS);
+ zhdr->first_chunks = zhdr->middle_chunks;
+ zhdr->middle_chunks = 0;
+ zhdr->start_middle = 0;
+ zhdr->first_num++;
+ ret = 1;
goto out;
+ }
- if (zhdr->middle_chunks != 0) {
- if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
- mchunk_memmove(zhdr, 1); /* move to the beginning */
- zhdr->first_chunks = zhdr->middle_chunks;
- zhdr->middle_chunks = 0;
- zhdr->start_middle = 0;
- zhdr->first_num++;
- ret = 1;
- goto out;
- }
-
- /*
- * moving data is expensive, so let's only do that if
- * there's substantial gain (at least BIG_CHUNK_GAP chunks)
- */
- if (zhdr->first_chunks != 0 && zhdr->last_chunks == 0 &&
- zhdr->start_middle > zhdr->first_chunks + BIG_CHUNK_GAP) {
- mchunk_memmove(zhdr, zhdr->first_chunks + 1);
- zhdr->start_middle = zhdr->first_chunks + 1;
- ret = 1;
- goto out;
- }
- if (zhdr->last_chunks != 0 && zhdr->first_chunks == 0 &&
- zhdr->middle_chunks + zhdr->last_chunks <=
- NCHUNKS - zhdr->start_middle - BIG_CHUNK_GAP) {
- unsigned short new_start = NCHUNKS - zhdr->last_chunks -
- zhdr->middle_chunks;
- mchunk_memmove(zhdr, new_start);
- zhdr->start_middle = new_start;
- ret = 1;
- goto out;
- }
+ /*
+ * moving data is expensive, so let's only do that if
+ * there's substantial gain (at least BIG_CHUNK_GAP chunks)
+ */
+ if (zhdr->first_chunks != 0 && zhdr->last_chunks == 0 &&
+ zhdr->start_middle - (zhdr->first_chunks + ZHDR_CHUNKS) >=
+ BIG_CHUNK_GAP) {
+ /* new_start: right after 1st chunk */
+ unsigned short new_start = zhdr->first_chunks + ZHDR_CHUNKS;
+ mchunk_memmove(zhdr, new_start);
+ zhdr->start_middle = new_start;
+ ret = 1;
+ goto out;
+ }
+ if (zhdr->last_chunks != 0 && zhdr->first_chunks == 0 &&
+ TOTAL_CHUNKS -
+ (zhdr->last_chunks + zhdr->start_middle + zhdr->middle_chunks) >=
+ BIG_CHUNK_GAP) {
+ /* new_start: right before last chunk */
+ unsigned short new_start = TOTAL_CHUNKS -
+ (zhdr->last_chunks + zhdr->middle_chunks);
+ mchunk_memmove(zhdr, new_start);
+ zhdr->start_middle = new_start;
+ ret = 1;
+ goto out;
}
out:
return ret;
@@ -425,7 +438,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
zhdr->last_chunks = chunks;
else {
zhdr->middle_chunks = chunks;
- zhdr->start_middle = zhdr->first_chunks + 1;
+ zhdr->start_middle = zhdr->first_chunks + ZHDR_CHUNKS;
}
spin_lock(&pool->lock);
@@ -870,8 +883,8 @@ MODULE_ALIAS("zpool-z3fold");
static int __init init_z3fold(void)
{
- /* Make sure the z3fold header will fit in one chunk */
- BUILD_BUG_ON(sizeof(struct z3fold_header) > ZHDR_SIZE_ALIGNED);
+ /* Make sure the z3fold header is not larger than the page size */
+ BUILD_BUG_ON(ZHDR_SIZE_ALIGNED > PAGE_SIZE);
zpool_register_driver(&z3fold_zpool_driver);
return 0;
--
2.4.2
[toc] | [prev] | [next] | [standalone]
| From | Vitaly Wool <vitalywool@gmail.com> |
|---|---|
| Date | 2016-11-26 20:30 +0100 |
| Subject | [PATCH 2/2] z3fold: fix locking issues |
| Message-ID | <sHQPE-2k9-11@gated-at.bofh.it> |
| In reply to | #1530765 |
Commit 570931c ("z3fold: use per-page spinlock") introduced locking
issues in reclaim function reported in [1] and [2]. This patch
addresses these issues, also fixing the check for empty lru list
(it was only checked once, while it should be checked every time
we want to get the last lru entry).
[1] https://lkml.org/lkml/2016/11/25/628
[2] http://www.spinics.net/lists/linux-mm/msg117227.html
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
---
mm/z3fold.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index efbcfcc..729a2da 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -607,12 +607,15 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
unsigned long first_handle = 0, middle_handle = 0, last_handle = 0;
spin_lock(&pool->lock);
- if (!pool->ops || !pool->ops->evict || list_empty(&pool->lru) ||
- retries == 0) {
+ if (!pool->ops || !pool->ops->evict || retries == 0) {
spin_unlock(&pool->lock);
return -EINVAL;
}
for (i = 0; i < retries; i++) {
+ if (list_empty(&pool->lru)) {
+ spin_unlock(&pool->lock);
+ return -EINVAL;
+ }
page = list_last_entry(&pool->lru, struct page, lru);
list_del(&page->lru);
@@ -671,8 +674,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
* All buddies are now free, free the z3fold page and
* return success.
*/
- clear_bit(PAGE_HEADLESS, &page->private);
- if (!test_bit(PAGE_HEADLESS, &page->private))
+ if (!test_and_clear_bit(PAGE_HEADLESS, &page->private))
z3fold_page_unlock(zhdr);
free_z3fold_page(zhdr);
atomic64_dec(&pool->pages_nr);
@@ -684,6 +686,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
/* Full, add to buddied list */
spin_lock(&pool->lock);
list_add(&zhdr->buddy, &pool->buddied);
+ spin_unlock(&pool->lock);
} else {
z3fold_compact_page(zhdr);
/* add to unbuddied list */
@@ -691,15 +694,18 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
freechunks = num_free_chunks(zhdr);
list_add(&zhdr->buddy,
&pool->unbuddied[freechunks]);
+ spin_unlock(&pool->lock);
}
}
+ if (!test_bit(PAGE_HEADLESS, &page->private))
+ z3fold_page_unlock(zhdr);
+
+ spin_lock(&pool->lock);
/* add to beginning of LRU */
list_add(&page->lru, &pool->lru);
}
spin_unlock(&pool->lock);
- if (!test_bit(PAGE_HEADLESS, &page->private))
- z3fold_page_unlock(zhdr);
return -EAGAIN;
}
--
2.4.2
[toc] | [prev] | [next] | [standalone]
| From | Dan Streetman <ddstreet@ieee.org> |
|---|---|
| Date | 2016-11-29 23:40 +0100 |
| Message-ID | <sIZe9-63P-9@gated-at.bofh.it> |
| In reply to | #1530765 |
On Sat, Nov 26, 2016 at 2:15 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> Here come 2 patches with z3fold fixes for chunks counting and locking. As commit 50a50d2 ("z3fold: don't fail kernel build is z3fold_header is too big") was NAK'ed [1], I would suggest that we removed that one and the next z3fold commit cc1e9c8 ("z3fold: discourage use of pages that weren't compacted") and applied the coming 2 instead.
Instead of adding these onto all the previous ones, could you redo the
entire z3fold series? I think it'll be simpler to review the series
all at once and that would remove some of the stuff from previous
patches that shouldn't be there.
If that's ok with Andrew, of course, but I don't think any of the
z3fold patches have been pushed to Linus yet.
>
> Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
>
> [1] https://lkml.org/lkml/2016/11/25/595
[toc] | [prev] | [next] | [standalone]
| From | Andrew Morton <akpm@linux-foundation.org> |
|---|---|
| Date | 2016-11-29 23:40 +0100 |
| Message-ID | <sIZe9-63P-13@gated-at.bofh.it> |
| In reply to | #1532825 |
On Tue, 29 Nov 2016 17:33:19 -0500 Dan Streetman <ddstreet@ieee.org> wrote:
> On Sat, Nov 26, 2016 at 2:15 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> > Here come 2 patches with z3fold fixes for chunks counting and locking. As commit 50a50d2 ("z3fold: don't fail kernel build is z3fold_header is too big") was NAK'ed [1], I would suggest that we removed that one and the next z3fold commit cc1e9c8 ("z3fold: discourage use of pages that weren't compacted") and applied the coming 2 instead.
>
> Instead of adding these onto all the previous ones, could you redo the
> entire z3fold series? I think it'll be simpler to review the series
> all at once and that would remove some of the stuff from previous
> patches that shouldn't be there.
>
> If that's ok with Andrew, of course, but I don't think any of the
> z3fold patches have been pushed to Linus yet.
Sounds good to me. I had a few surprise rejects when merging these
two, which indicates that things might be out of sync.
I presently have:
z3fold-limit-first_num-to-the-actual-range-of-possible-buddy-indexes.patch
z3fold-make-pages_nr-atomic.patch
z3fold-extend-compaction-function.patch
z3fold-use-per-page-spinlock.patch
z3fold-discourage-use-of-pages-that-werent-compacted.patch
z3fold-fix-header-size-related-issues.patch
z3fold-fix-locking-issues.patch
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web