[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO
From:       Linus Torvalds <torvalds () linux-foundation ! org>
Date:       2024-05-14 16:04:15
Message-ID: CAHk-=whob6O3m8KUJjnGzFDVHwb_PLueMP-YMtX1PxE9awTxcw () mail ! gmail ! com
[Download RAW message or body]

On Tue, 14 May 2024 at 04:52, Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Mon, Feb 26, 2024 at 02:46:56PM -0800, Linus Torvalds wrote:
> > I really haven't tested this AT ALL. I'm much too scared. But I don't
> > actually hate how the code looks nearly as much as I *thought* I'd
> > hate it.
>
> Thanks for this, obviously those interested in this will have to test
> this and fix the below issues. I've tested for regressions just against
> xfs on 4k reflink profile and detected only two failures, generic/095
> fails with a failure rate of about 1/2 or so:
>
>   * generic/095
>   * generic/741

Funky.

I do *not* see how those can fail due to the change, but that's the
point of testing.

Somebody who knows those two tests better, and figures out what the
difference is would have to get involved.

One different thing that my fast-read case does is that it does *NOT*
do the crazy dcache coherency thing that the "full" case does, ie the

                writably_mapped = mapping_writably_mapped(mapping);
                ...
                        /*
                         * If users can be writing to this folio using arbitrary
                         * virtual addresses, take care of potential aliasing
                         * before reading the folio on the kernel side.
                         */
                        if (writably_mapped)
                                flush_dcache_folio(folio);

but that shouldn't matter on any sane architecture. Sadly, even arm64
counts as "insane" here, because it does the I$ sync using
flush_dcache_folio().

I can't tell what architecture the testing was done on, but I assume
it was x86, and I assume the above detail is _not_ the cause.

               Linus

[prev in list] [next in list] [prev in thread] [next in thread]