On 29/07/21(Thu) 15:36, Alexander Bluhm wrote:
> > > New diff fixing a locking dance pointed out by visa@.
>
> Not tested this one yet. But here is a combination of all the
> others.
>
> http://bluhm.genua.de/perform/results/2021-07-27T07:41:29Z/perform.html
Thanks for testing.
These tests sho
> > New diff fixing a locking dance pointed out by visa@.
Not tested this one yet. But here is a combination of all the
others.
http://bluhm.genua.de/perform/results/2021-07-27T07:41:29Z/perform.html
bluhm
On Thu, Jul 29, 2021 at 09:51:43AM +0200, Martin Pieuchot wrote:
> On 26/07/21(Mon) 09:23, Martin Pieuchot wrote:
> > On 26/07/21(Mon) 08:55, Martin Pieuchot wrote:
> > > On 21/07/21(Wed) 10:18, Martin Pieuchot wrote:
> > > > On 11/07/21(Sun) 14:45, Visa Hankala wrote:
> > > > > On Sat, Jul 10, 202
On 26/07/21(Mon) 09:23, Martin Pieuchot wrote:
> On 26/07/21(Mon) 08:55, Martin Pieuchot wrote:
> > On 21/07/21(Wed) 10:18, Martin Pieuchot wrote:
> > > On 11/07/21(Sun) 14:45, Visa Hankala wrote:
> > > > On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote:
> > > > > One of the reasons
On 26/07/21(Mon) 08:55, Martin Pieuchot wrote:
> On 21/07/21(Wed) 10:18, Martin Pieuchot wrote:
> > On 11/07/21(Sun) 14:45, Visa Hankala wrote:
> > > On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote:
> > > > One of the reasons for the drop of performances in the kqueue-based
> > > >
On 21/07/21(Wed) 10:18, Martin Pieuchot wrote:
> On 11/07/21(Sun) 14:45, Visa Hankala wrote:
> > On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote:
> > > One of the reasons for the drop of performances in the kqueue-based
> > > poll/select is the fact that kqueue filters are called up
On 11/07/21(Sun) 14:45, Visa Hankala wrote:
> On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote:
> > One of the reasons for the drop of performances in the kqueue-based
> > poll/select is the fact that kqueue filters are called up to 3 times
> > per syscall and that they all spin on t
On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote:
> One of the reasons for the drop of performances in the kqueue-based
> poll/select is the fact that kqueue filters are called up to 3 times
> per syscall and that they all spin on the NET_LOCK() for TCP/UDP
> packets.
>
> Diff below
Thanks for explanation. I missed the last commit to
sys/kern/uipc_socket.c
> On 10 Jul 2021, at 22:56, Martin Pieuchot wrote:
>
> On 10/07/21(Sat) 21:53, Vitaliy Makkoveev wrote:
>> Hi,
>>
>> In filt_solisten_common() you touches `so_qlen’ only. It’s not
>> related to buffer and not protected b
On 10/07/21(Sat) 21:53, Vitaliy Makkoveev wrote:
> Hi,
>
> In filt_solisten_common() you touches `so_qlen’ only. It’s not
> related to buffer and not protected by introduced `sb_mtx’ so
> the solock() replacement in filt_solisten*() is wrong.
>
> However, in filt_solisten_common() you only checks
Hi,
In filt_solisten_common() you touches `so_qlen’ only. It’s not
related to buffer and not protected by introduced `sb_mtx’ so
the solock() replacement in filt_solisten*() is wrong.
However, in filt_solisten_common() you only checks is
`so_qlen’ != 0 condition and such check could be performed
One of the reasons for the drop of performances in the kqueue-based
poll/select is the fact that kqueue filters are called up to 3 times
per syscall and that they all spin on the NET_LOCK() for TCP/UDP
packets.
Diff below is a RFC for improving the situation.
socket kqueue filters mainly check fo
12 matches
Mail list logo
