Peter Xu writes:
> On Mon, Feb 05, 2024 at 11:10:34AM -0300, Fabiano Rosas wrote:
>> > (maybe I can repost this single patch in-place to avoid another round of
>> > mail bombs..)
>>
>> Sure.
>
> I've got the final version attached here. Feel free to have a look, thanks.
>
>
> From
On Mon, Feb 05, 2024 at 11:10:34AM -0300, Fabiano Rosas wrote:
> > (maybe I can repost this single patch in-place to avoid another round of
> > mail bombs..)
>
> Sure.
I've got the final version attached here. Feel free to have a look, thanks.
>From
Peter Xu writes:
> On Fri, Feb 02, 2024 at 06:34:08PM -0300, Fabiano Rosas wrote:
>> pet...@redhat.com writes:
>>
>> > From: Peter Xu
>> >
>> > When reviewing my attempt to refactor send_prepare(), Fabiano suggested we
>> > try out with dropping the mutex in multifd code [1].
>> >
>> > I
On Fri, Feb 02, 2024 at 06:34:08PM -0300, Fabiano Rosas wrote:
> pet...@redhat.com writes:
>
> > From: Peter Xu
> >
> > When reviewing my attempt to refactor send_prepare(), Fabiano suggested we
> > try out with dropping the mutex in multifd code [1].
> >
> > I thought about that before but I
pet...@redhat.com writes:
> From: Peter Xu
>
> When reviewing my attempt to refactor send_prepare(), Fabiano suggested we
> try out with dropping the mutex in multifd code [1].
>
> I thought about that before but I never tried to change the code. Now
> maybe it's time to give it a stab. This
From: Peter Xu
When reviewing my attempt to refactor send_prepare(), Fabiano suggested we
try out with dropping the mutex in multifd code [1].
I thought about that before but I never tried to change the code. Now
maybe it's time to give it a stab. This only optimizes the sender side.
The
