f2fs: fix unnecessary periodic wakeup of discard thread when dev is busy

PATCH In review Sahitya Tummala 2 participants 4 messages Aug 31, 2018 – Sep 2, 2018 F2FS file system

Share & tools

Sahitya Tummala

author

2018-08-31 09:39 UTC #0 lore raw

PATCH 1/1 f2fs: fix unnecessary periodic wakeup of discard thread when dev is busy

When dev is busy, discard thread wake up timeout can be aligned with the exact time that it needs to wait for dev to come out of busy. This helps to avoid unnecessary periodic wakeups and thus save some power.

Signed-off-by Sahitya Tummala <[email protected]>

---
 fs/f2fs/segment.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

fs/f2fs/segment.c +7 -1

index 8bcbb50..df14030 100644
@@ -1379,6 +1379,8 @@ static int issue_discard_thread(void *data)
 	struct discard_policy dpolicy;
 	unsigned int wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
 	int issued;
+	unsigned long interval = sbi->interval_time[REQ_TIME] * HZ;
+	long delta;
 
 	set_freezable();

@@ -1410,7 +1412,11 @@ static int issue_discard_thread(void *data)
 			__wait_all_discard_cmd(sbi, &dpolicy);
 			wait_ms = dpolicy.min_interval;
 		} else if (issued == -1){
-			wait_ms = dpolicy.mid_interval;
+			delta = (sbi->last_time[REQ_TIME] + interval) - jiffies;
+			if (delta > 0)
+				wait_ms = jiffies_to_msecs(delta);
+			else
+				wait_ms = dpolicy.mid_interval;
 		} else {
 			wait_ms = dpolicy.max_interval;
 		}

Signature · 2 lines

Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Chao Yu

maintainer

2018-09-02 08:52 UTC #1 lore raw

Quoted 23 lines · Sahitya Tummala

When dev is busy, discard thread wake up timeout can be aligned with the exact time that it needs to wait for dev to come out of busy. This helps to avoid unnecessary periodic wakeups and thus save some power.
Signed-off-by Sahitya Tummala <[email protected]>
---
 fs/f2fs/segment.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
fs/f2fs/segment.c +2 -0
index 8bcbb50..df14030 100644
@@ -1379,6 +1379,8 @@ static int issue_discard_thread(void *data)
 	struct discard_policy dpolicy;
 	unsigned int wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
 	int issued;
+	unsigned long interval = sbi->interval_time[REQ_TIME] * HZ;
+	long delta;
 
 	set_freezable();
 

fs/f2fs/segment.c static int issue_discard_thread(void *data) · line 1415

Quoted 5 lines

fs/f2fs/segment.c +1 -1

@@ -1410,7 +1412,11 @@ static int issue_discard_thread(void *data)
 			__wait_all_discard_cmd(sbi, &dpolicy);
 			wait_ms = dpolicy.min_interval;
 		} else if (issued == -1){
-			wait_ms = dpolicy.mid_interval;
+			delta = (sbi->last_time[REQ_TIME] + interval) - jiffies;

I agree that we need to consider power consumption. One more consideration is that discard thread may need different submission frequency comparing to garbage collection thread, maybe a little fast, would it be better to split sbi->interval_time[REQ_TIME] according to gc/discard type.

How do you think?

Thanks,

Quoted 8 lines

fs/f2fs/segment.c +4 -0

+			if (delta > 0)
+				wait_ms = jiffies_to_msecs(delta);
+			else
+				wait_ms = dpolicy.mid_interval;
 		} else {
 			wait_ms = dpolicy.max_interval;
 		}

Sahitya Tummala

author

2018-09-02 10:34 UTC #2 lore raw

Quoted 35 lines · Chao Yu

Quoted 23 lines · Sahitya Tummala
When dev is busy, discard thread wake up timeout can be aligned with the exact time that it needs to wait for dev to come out of busy. This helps to avoid unnecessary periodic wakeups and thus save some power.
Signed-off-by Sahitya Tummala <[email protected]>
---
 fs/f2fs/segment.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
fs/f2fs/segment.c +2 -0
index 8bcbb50..df14030 100644
@@ -1379,6 +1379,8 @@ static int issue_discard_thread(void *data)
 	struct discard_policy dpolicy;
 	unsigned int wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
 	int issued;
+	unsigned long interval = sbi->interval_time[REQ_TIME] * HZ;
+	long delta;
 
 	set_freezable();
 
fs/f2fs/segment.c static int issue_discard_thread(void *data) · line 1415
Quoted 5 lines
fs/f2fs/segment.c +1 -1
@@ -1410,7 +1412,11 @@ static int issue_discard_thread(void *data)
 			__wait_all_discard_cmd(sbi, &dpolicy);
 			wait_ms = dpolicy.min_interval;
 		} else if (issued == -1){
-			wait_ms = dpolicy.mid_interval;
+			delta = (sbi->last_time[REQ_TIME] + interval) - jiffies;
I agree that we need to consider power consumption. One more consideration is that discard thread may need different submission frequency comparing to garbage collection thread, maybe a little fast, would it be better to split sbi->interval_time[REQ_TIME] according to gc/discard type.

Quoted 4 lines

How do you think?
Thanks,

Thanks for the review.

You mean when GC type is urgent? I see that for that case, the discard policy is changed to DPOLICY_FORCE, which sets dpolicy->io_aware as false and hence, cannot fall into this (issued == -1) case at all.

Quoted 8 lines

fs/f2fs/segment.c +4 -0

+			if (delta > 0)
+				wait_ms = jiffies_to_msecs(delta);
+			else
+				wait_ms = dpolicy.mid_interval;
 		} else {
 			wait_ms = dpolicy.max_interval;
 		}

Signature · 7 lines

--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Chao Yu

maintainer Reviewed-by

2018-09-02 12:56 UTC #3 lore raw

Quoted 36 lines · Sahitya Tummala

Quoted 35 lines · Chao Yu
Quoted 23 lines · Sahitya Tummala
When dev is busy, discard thread wake up timeout can be aligned with the exact time that it needs to wait for dev to come out of busy. This helps to avoid unnecessary periodic wakeups and thus save some power.
Signed-off-by Sahitya Tummala <[email protected]>
---
 fs/f2fs/segment.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
fs/f2fs/segment.c +2 -0
index 8bcbb50..df14030 100644
@@ -1379,6 +1379,8 @@ static int issue_discard_thread(void *data)
 	struct discard_policy dpolicy;
 	unsigned int wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
 	int issued;
+	unsigned long interval = sbi->interval_time[REQ_TIME] * HZ;
+	long delta;
 
 	set_freezable();
 
fs/f2fs/segment.c static int issue_discard_thread(void *data) · line 1415
Quoted 5 lines
fs/f2fs/segment.c +1 -1
@@ -1410,7 +1412,11 @@ static int issue_discard_thread(void *data)
 			__wait_all_discard_cmd(sbi, &dpolicy);
 			wait_ms = dpolicy.min_interval;
 		} else if (issued == -1){
-			wait_ms = dpolicy.mid_interval;
+			delta = (sbi->last_time[REQ_TIME] + interval) - jiffies;
I agree that we need to consider power consumption. One more consideration is that discard thread may need different submission frequency comparing to garbage collection thread, maybe a little fast, would it be better to split sbi->interval_time[REQ_TIME] according to gc/discard type.

Quoted 8 lines

Quoted 4 lines
How do you think?
Thanks,
Thanks for the review.
You mean when GC type is urgent? I see that for that case, the discard policy is

Actually, I mean splitting sbi->interval_time[REQ_TIME] into:
- sbi->interval_time[GC_TIM] which can be used for GC thread.
- sbi->interval_time[DISCARD_TIME] which can be used for Discard thread.

Then we can configure sbi->interval_time[DISCARD_TIME] independently, and set more suitable interval value for discard thread, since discard thread may need to wake to submit discards more frequently.

I guess if we can accept above idea, it can be sent as another patch, so anyway, I'm okay with your change. :)

Reviewed-by Chao Yu <[email protected]>

Thanks,

Quoted 12 lines

changed to DPOLICY_FORCE, which sets dpolicy->io_aware as false and hence, cannot fall into this (issued == -1) case at all.
Quoted 8 lines
Quoted 8 lines
fs/f2fs/segment.c +4 -0
+			if (delta > 0)
+				wait_ms = jiffies_to_msecs(delta);
+			else
+				wait_ms = dpolicy.mid_interval;
 		} else {
 			wait_ms = dpolicy.max_interval;
 		}