From: Xiubo Li <xiubli(a)redhat.com>
Blindly expanding the readahead windows will cause unneccessary
pagecache thrashing and also will introdue the network workload.
We should disable expanding the windows if the readahead is disabled
and also shouldn't expand the windows too much.
Expanding forward firstly instead of expanding backward for possible
sequential reads.
Bound `rreq->len` to the actual file size to restore the previous page
cache usage.
The posix_fadvise may change the maximum size of a file readahead.
Cc: stable(a)vger.kernel.org
Fixes: 49870056005c ("ceph: convert ceph_readpages to ceph_readahead")
URL: https://lore.kernel.org/ceph-devel/20230504082510.247-1-sehuww@mail.scut.ed…
URL: https://www.spinics.net/lists/ceph-users/msg76183.html
Cc: Hu Weiwen <sehuww(a)mail.scut.edu.cn>
Signed-off-by: Xiubo Li <xiubli(a)redhat.com>
---
fs/ceph/addr.c | 40 +++++++++++++++++++++++++++++++++-------
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 93fff1a7373f..4b29777c01d7 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -188,16 +188,42 @@ static void ceph_netfs_expand_readahead(struct netfs_io_request *rreq)
struct inode *inode = rreq->inode;
struct ceph_inode_info *ci = ceph_inode(inode);
struct ceph_file_layout *lo = &ci->i_layout;
+ unsigned long max_pages = inode->i_sb->s_bdi->ra_pages;
+ loff_t end = rreq->start + rreq->len, new_end;
+ struct ceph_netfs_request_data *priv = rreq->netfs_priv;
+ unsigned long max_len;
u32 blockoff;
- u64 blockno;
- /* Expand the start downward */
- blockno = div_u64_rem(rreq->start, lo->stripe_unit, &blockoff);
- rreq->start = blockno * lo->stripe_unit;
- rreq->len += blockoff;
+ if (priv) {
+ /* Readahead is disabled by posix_fadvise POSIX_FADV_RANDOM */
+ if (priv->file_ra_disabled)
+ max_pages = 0;
+ else
+ max_pages = priv->file_ra_pages;
+
+ }
+
+ /* Readahead is disabled */
+ if (!max_pages)
+ return;
- /* Now, round up the length to the next block */
- rreq->len = roundup(rreq->len, lo->stripe_unit);
+ max_len = max_pages << PAGE_SHIFT;
+
+ /*
+ * Try to expand the length forward by rounding up it to the next
+ * block, but do not exceed the file size, unless the original
+ * request already exceeds it.
+ */
+ new_end = min(round_up(end, lo->stripe_unit), rreq->i_size);
+ if (new_end > end && new_end <= rreq->start + max_len)
+ rreq->len = new_end - rreq->start;
+
+ /* Try to expand the start downward */
+ div_u64_rem(rreq->start, lo->stripe_unit, &blockoff);
+ if (rreq->len + blockoff <= max_len) {
+ rreq->start -= blockoff;
+ rreq->len += blockoff;
+ }
}
static bool ceph_netfs_clamp_length(struct netfs_io_subrequest *subreq)
--
2.40.1
Hi,
Sasha's auto-selection backported:
commit f3f8f16b10f8 ("drm/amd/display: enable DPG when disabling plane
for phantom pipe") from 6.4 into 6.3.y as
commit ef6c86d067b4 ("drm/amd/display: enable DPG when disabling plane
for phantom pipe")
This was bisected down to have caused a regression in both 6.3.4 and 6.3.5:
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2581
The problematic behavior doesn't occur in 6.4-rc4.
This is confirmed to fixed on 6.3.y by backporting an additional commit:
82a10aff9428 ("drm/amd/display: Only wait for blank completion if OTG
active")||
Can you please backport this to 6.3.y to fix this regression?
Thanks!
PEACE BE WITH YOU,
Receiving this message might sound as a surprise to you, please do
accept it as a blessing from God made possible through a woman (widow)
with a good and sincere heart towards the poor orphans. Through these
projects millions will be positively touched as with God nothing is
impossible. I have this strong desire to help the poor orphans
suffering each day, but this dream cannot be realised as a result of
my health, which does not improve, hence I do not know whether I will
survive having undergone different surgical operations, which has kept
me hospitalized. Right now, life gives me no choice, but to answer the
call (death); my prayers each day is to have a place in Heaven. I have
suffered a lot as a result of this incurable sickness (terminal
cancer)! Above all, I do not have a child as a result of my sterility.
The only help I need from you at this point is to be in constant
prayers with me as I believe you have an open heart towards the poor
orphans and do believe in GOD. I would be so much happy to see that my
funds (Eight million Five Hundred United State Dollars) 8.5 Million
USD are properly used to help the less privileged etc before leaving
this world as this will be a great relieve for me and my soul. This is
a huge responsibility, but I pray that God gives you the strength to
handle it. You will also be highly recompensated.
Therefore, I want you to receive the money and take 30% to take care
of yourself and family while 70% should be used basically on
humanitarian purposes mostly to orphanages, Motherless babies home,
less privileged and disable citizens and widows around the world.
Once I get your reply, I will put you in contact with the bank in
charge of the transaction in order to start all necessary procedures
so as to enable you to have possession of my funds as soon as possible
before my next surgical operations.
I looking forward to reading from you.( mirabelvicent01(a)gmail.com )
Mrs. Mirabel Vicent..
From: Tian Lan <tian.lan(a)twosigma.com>
The nr_active counter continues to increase over time which causes the
blk_mq_get_tag to hang until the thread is rescheduled to a different
core despite there are still tags available.
kernel-stack
INFO: task inboundIOReacto:3014879 blocked for more than 2 seconds
Not tainted 6.1.15-amd64 #1 Debian 6.1.15~debian11
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:inboundIORe state:D stack:0 pid:3014879 ppid:4557 flags:0x00000000
Call Trace:
<TASK>
__schedule+0x351/0xa20
scheduler+0x5d/0xe0
io_schedule+0x42/0x70
blk_mq_get_tag+0x11a/0x2a0
? dequeue_task_stop+0x70/0x70
__blk_mq_alloc_requests+0x191/0x2e0
kprobe output showing RQF_MQ_INFLIGHT bit is not cleared before
__blk_mq_free_request being called.
320 320 kworker/29:1H __blk_mq_free_request rq_flags 0x220c0
b'__blk_mq_free_request+0x1 [kernel]'
b'bt_iter+0x50 [kernel]'
b'blk_mq_queue_tag_busy_iter+0x318 [kernel]'
b'blk_mq_timeout_work+0x7c [kernel]'
b'process_one_work+0x1c4 [kernel]'
b'worker_thread+0x4d [kernel]'
b'kthread+0xe6 [kernel]'
b'ret_from_fork+0x1f [kernel]'
This issue arises when both bt_iter() and blk_mq_end_request_batch()
are iterating on the same request. The leak happens when
blk_mq_find_and_get_req() is executed(from bt_iter) before
req_ref_put_and_test() gets called by blk_mq_end_request_batch().
And because non-flush request freed by blk_mq_put_rq_ref() bypasses the
active request tracking, the counter would slowly leak overtime.
Fixes: f794f3351f26 ("block: add support for blk_mq_end_request_batch()")
Fixes: 2e315dc07df0 ("blk-mq: grab rq->refcount before calling ->fn in blk_mq_tagset_busy_iter")
Signed-off-by: Tian Lan <tian.lan(a)twosigma.com>
Reviewed-by: Ming Lei <ming.lei(a)redhat.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.de>
Cc: stable(a)vger.kernel.org
---
block/blk-mq.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index f6dad0886a2f..850bfb844ed2 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -683,6 +683,10 @@ static void __blk_mq_free_request(struct request *rq)
blk_crypto_free_request(rq);
blk_pm_mark_last_busy(rq);
rq->mq_hctx = NULL;
+
+ if (rq->rq_flags & RQF_MQ_INFLIGHT)
+ __blk_mq_dec_active_requests(hctx);
+
if (rq->tag != BLK_MQ_NO_TAG)
blk_mq_put_tag(hctx->tags, ctx, rq->tag);
if (sched_tag != BLK_MQ_NO_TAG)
@@ -694,15 +698,11 @@ static void __blk_mq_free_request(struct request *rq)
void blk_mq_free_request(struct request *rq)
{
struct request_queue *q = rq->q;
- struct blk_mq_hw_ctx *hctx = rq->mq_hctx;
if ((rq->rq_flags & RQF_ELVPRIV) &&
q->elevator->type->ops.finish_request)
q->elevator->type->ops.finish_request(rq);
- if (rq->rq_flags & RQF_MQ_INFLIGHT)
- __blk_mq_dec_active_requests(hctx);
-
if (unlikely(laptop_mode && !blk_rq_is_passthrough(rq)))
laptop_io_completion(q->disk->bdi);
--
2.25.1