From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/1] readahead02: Sleep 1.5 msec to fix problem on bare metal
Date: Fri, 21 Nov 2025 11:45:06 +0100 [thread overview]
Message-ID: <20251121104506.GA25561@pevik> (raw)
In-Reply-To: <aSBBzVaq4gJ6JfrK@yuki.lan>
> Hi!
> > This fixes ppc64le bare metal. It looks like kernel needs some time to
> > update counters.
> In this case I think that something is needed for the kernel to actually
> do some readahead. The readahead() syscall is supposed to initiate
> readahead but kernel will need some time for the actual readahead to
> happen. And how much time will depend on the I/O speed and saturation of
> the I/O bus/disk.
> Adding a short sleep is a good start. However I'm afraid that we will
> need a bit more complex solution to this problem. Maybe do a short
> sleep, check the cache size and if it increased more than some
> threshold, sleep again.
> Something as:
> int retries = MAX_RETRIES;
> unsigned long cached_prev, cached_cur = get_cached_size();
> do {
> usleep(SHORT_SLEEP);
> cached_prev = cached_cur;
> cached_cur = get_cached_size();
> if (cached_cur < cached_prev)
> break;
> if (cached_cur-cached_prev < CACHE_INC_THRESHOLD)
> break;
> } while (retries-- > 0);
Yeah, few loops with shorter usleep() and proactive checking is for sure way
better than single usleep(). Will you please have time to send the above as a
patch? I'll test it for you.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2025-11-21 10:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 16:35 [LTP] [PATCH 1/1] readahead02: Sleep 1.5 msec to fix problem on bare metal Petr Vorel
2025-11-21 10:41 ` Cyril Hrubis
2025-11-21 10:45 ` Petr Vorel [this message]
2025-11-21 11:42 ` Cyril Hrubis
2025-11-21 11:48 ` Cyril Hrubis
2025-11-24 9:14 ` Jan Stancek via ltp
2025-11-24 9:18 ` Cyril Hrubis
2025-11-24 9:20 ` Petr Vorel
2025-11-24 9:20 ` Jan Stancek via ltp
2025-11-24 12:58 ` Li Wang via ltp
2025-11-24 13:18 ` Cyril Hrubis
2025-11-24 13:20 ` Li Wang via ltp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251121104506.GA25561@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.