Subject: + zram-support-req_discard-v4.patch added to -mm tree
To: iamjoonsoo.kim@xxxxxxx,jmarchan@xxxxxxxxxx,minchan@xxxxxxxxxx,ngupta@xxxxxxxxxx,sergey.senozhatsky@xxxxxxxxx
From: akpm@xxxxxxxxxxxxxxxxxxxx
Date: Thu, 13 Mar 2014 13:40:41 -0700
The patch titled
Subject: zram-support-req_discard-v4
has been added to the -mm tree. Its filename is
zram-support-req_discard-v4.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/zram-support-req_discard-v4.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/zram-support-req_discard-v4.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
Subject: zram-support-req_discard-v4
v4: replenish code comments suggested by Andrew.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
Cc: Minchan Kim <minchan@xxxxxxxxxx>
Cc: Nitin Gupta <ngupta@xxxxxxxxxx>
Cc: Sergey Senozhatsky <sergey.senozhatsky@xxxxxxxxx>
Cc: Jerome Marchand <jmarchan@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
drivers/block/zram/zram_drv.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff -puN drivers/block/zram/zram_drv.c~zram-support-req_discard-v4 drivers/block/zram/zram_drv.c
--- a/drivers/block/zram/zram_drv.c~zram-support-req_discard-v4
+++ a/drivers/block/zram/zram_drv.c
@@ -550,15 +550,25 @@ static int zram_bvec_rw(struct zram *zra
return ret;
}
+/*
+ * zram_bio_discard - handler on discard request
+ * @index: physical block index by PAGE_SIZE unit
+ * @offset: offset within physical block
+ */
static void zram_bio_discard(struct zram *zram, u32 index,
int offset, struct bio *bio)
{
size_t n = bio->bi_iter.bi_size;
/*
- * On some arch, logical block (4096) aligned request couldn't be
- * aligned to PAGE_SIZE, since their PAGE_SIZE aren't 4096.
- * Therefore we should handle this misaligned case here.
+ * zram manages data by physical block size unit. Because logical block
+ * size isn't identical with physical block size on some arch, we
+ * could get discard request pointing to specific offset within certain
+ * physical block. Although we can handle this request by reading that
+ * physiclal block and decompressing and partially zeroing and
+ * re-compressing and then re-storing it, it isn't reasonable because
+ * our intention of handling discard request is to save memory.
+ * So skipping this logical block is approriate here.
*/
if (offset) {
if (n < offset)
@@ -569,6 +579,11 @@ static void zram_bio_discard(struct zram
}
while (n >= PAGE_SIZE) {
+ /*
+ * discard request can be too large so that the zram can
+ * be stucked for a long time if we handle the request
+ * at once. So handle the request by PAGE_SIZE unit at a time.
+ */
write_lock(&zram->meta->tb_lock);
zram_free_page(zram, index);
write_unlock(&zram->meta->tb_lock);
@@ -890,8 +905,11 @@ static int create_device(struct zram *zr
zram->disk->queue->limits.discard_granularity = PAGE_SIZE;
zram->disk->queue->limits.max_discard_sectors = UINT_MAX;
/*
- * We will skip to discard mis-aligned range, so we can't ensure
- * whether discarded region is zero or not.
+ * zram_bio_discard() will clear all logical blocks if logical block
+ * size is identical with physical block size(PAGE_SIZE). But if it is
+ * different, we will skip to discard some parts of logical blocks in
+ * whole request range which isn't aligned to physical block size.
+ * So we can't ensure that some discarded logical block is zeroed.
*/
if (ZRAM_LOGICAL_BLOCK_SIZE == PAGE_SIZE)
zram->disk->queue->limits.discard_zeroes_data = 1;
_
Patches currently in -mm which might be from iamjoonsoo.kim@xxxxxxx are
origin.patch
slub-fix-high-order-page-allocation-problem-with-__gfp_nofail.patch
kthread-ensure-locality-of-task_struct-allocations.patch
mm-hugetlb-unify-region-structure-handling.patch
mm-hugetlb-improve-cleanup-resv_map-parameters.patch
mm-hugetlb-fix-race-in-region-tracking.patch
mm-hugetlb-remove-resv_map_put.patch
mm-hugetlb-use-vma_resv_map-map-types.patch
mm-hugetlb-improve-page-fault-scalability.patch
mm-hugetlb-improve-page-fault-scalability-fix.patch
mm-hugetlb-mark-some-bootstrap-functions-as-__init.patch
mm-compaction-avoid-isolating-pinned-pages.patch
mm-compaction-disallow-high-order-page-for-migration-target.patch
mm-compaction-do-not-call-suitable_migration_target-on-every-page.patch
mm-compaction-change-the-timing-to-check-to-drop-the-spinlock.patch
mm-compaction-check-pageblock-suitability-once-per-pageblock.patch
mm-compaction-clean-up-code-on-success-of-ballon-isolation.patch
mm-compactionc-isolate_freepages_block-small-tuneup.patch
mm-compaction-determine-isolation-mode-only-once.patch
mm-vmallocc-enhance-vm_map_ram-comment.patch
mm-vmallocc-enhance-vm_map_ram-comment-fix.patch
zram-support-req_discard.patch
zram-support-req_discard-v4.patch
zram-support-req_discard-v4-fix.patch
page-owners-correct-page-order-when-to-free-page.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
