On Mon, 2024-07-22 at 13:19 +0200, Bruno Haible wrote:
> Hi Jeff,
>
> Thanks for the info.
>
> > Unfortunately, these patches aren't in rawhide kernels yet. Christian
> > will pull these into his tree once the dust settles from the merge
> > window. Once that happens, it should go into rawhide so
On Mon, 2024-07-22 at 13:19 +0200, Bruno Haible wrote:
> Hi Jeff,
>
> Thanks for the info.
>
> > Unfortunately, these patches aren't in rawhide kernels yet. Christian
> > will pull these into his tree once the dust settles from the merge
> > window. Once that happens, it should go into rawhide so
Hi Jeff,
Thanks for the info.
> Unfortunately, these patches aren't in rawhide kernels yet. Christian
> will pull these into his tree once the dust settles from the merge
> window. Once that happens, it should go into rawhide soon after.
Can you please ping me when this happens or is about to ha
On Sun, 2024-07-21 at 02:49 +0200, Bruno Haible wrote:
> Hi Jeff,
>
> You wrote on 2024-06-28:
> > There are some proposed changes [1] to track finer-grained timestamps in
> > the Linux kernel that will break the assumptions that nap() uses to
> > gauge the delay. In particular, writing to a file
Hi Jeff,
You wrote on 2024-06-28:
> There are some proposed changes [1] to track finer-grained timestamps in
> the Linux kernel that will break the assumptions that nap() uses to
> gauge the delay. In particular, writing to a file will almost always
> show a change in the timestamp now, so usually
On Sat, 2024-06-29 at 03:33 +0200, Bruno Haible wrote:
> Jeff Layton wrote:
> > Failure of the test-stat-time test is what triggered us to revert the
> > multigrain timestamp series from the Linux kernel last October. With
> > that failure, we'd sometimes see timestamps showing files being modifie
Jeff Layton wrote:
> Failure of the test-stat-time test is what triggered us to revert the
> multigrain timestamp series from the Linux kernel last October. With
> that failure, we'd sometimes see timestamps showing files being modified
> in reverse order (if one got a fine-grained and another got
The current test in nap.h tries to gauge the minimum delay that results
in a timestamp change when successively writing to a file.
There are some proposed changes [1] to track finer-grained timestamps in
the Linux kernel that will break the assumptions that nap() uses to
gauge the delay. In partic
