Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
From:   Benjamin Coddington <bcodding@redhat.com>
To:     =?utf-8?q?Elias_N=C3=A4slund?= <elias.naslund@kd.kongsberg.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: Writing to NFS interfere with other threads in the same process
Date:   Tue, 24 Oct 2023 07:21:50 -0400
Message-ID: <FCF5E1D2-5DFD-4AA6-9BCF-7C902FFCCC80@redhat.com>
In-Reply-To: <PRAP190MB1833A3FAB75002DD5467B8ABCBDFA@PRAP190MB1833.EURP190.PROD.OUTLOOK.COM>
References: <PRAP190MB1833A3FAB75002DD5467B8ABCBDFA@PRAP190MB1833.EURP190.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 24 Oct 2023, at 1:20, Elias N=C3=A4slund wrote:

> In an embedded application we're running a Yocto based linux distrubuti=
on with RT patches. One thread is writing data to a file on a NFS and ano=
ther thread is once every second running chronyc tracking with popen.
> The hardware is a dual core ARM with 1 gb of memory.
>
> The problem is that chronyc tracking doesn't return within 100 ms if bo=
th threads runs in the same application. If, however, each thread runs in=
 its own process it works as expected. It takes normally 10-20ms for chro=
nyc tracking to return.

The write_file() thread is queuing up a lot of async IO that is then
flushed by chronyc's do_exit -> put_files_struct -> filp_close, which wil=
l
be a synchronous wait for all that IO.

If that's not what you want I think you'll want to figure out how to drop=

CLONE_FILES from std::thread's clone(2) syscall.

Ben