Hello Pablo, I understand this. It will save wakeups while master thread is busy with messages but not if the messages come with such gap that causes master thread to send them one by one for every w
Hi Julian, Why 32? If you do up() once per message, you will still get an arbitrary number of messages in the queue until the scheduler selects your thread to enter the running state. Well, this is n
Hello, OK, now I added up(). It will be called when 32 messages are queued after last sent by thread. Done, used same value both for rcvbuf and sndbuf. Yes, both values are for same thing, the proble
Hi Julian, You can still use kthread_should_stop inside a wrapper function that calls kthread_stop and up() the semaphore. sync_stop: kthread_stop(k) up(s) kthread_routine: while(1) { down(s) if (kth
Hello, May be it is possible to use up/down but we have to handle the kthread_should_stop check and also I prefer to reduce the wakeup events. So, I'm trying another solution which is appended just f
Hi Julian, I see, see below. I was refering to the situation in which you decide to delay sync messages due to congestion. State sync needs to be soft real-time to ensure that the backup is one copy-
Hello, Agreed, packet processing does not check for any limits for the sync_queues lists. This can be addressed additionally, may be there can be some wakeup if threshold is reached, so that we wake
Hi Simon et al. I see. You are avoiding the congestion in the socket queue by putting the pressure in your sync_buff queue (I don't find any limit in the code for the amount of memory that it may con
High rate of sync messages in master can lead to overflowing the socket buffer and dropping the messages. Instead of using fixed pause try to adapt to the sync rate, so that we do not wakeup too ofte