>> Is there any limitation anywhere that dictates the relationship between >> these two priorities? > Since they run synchronously and generally don't overlap in time, I > would say that the answer is no
I think this answers my question, thank you. So, It doesn't really matter what the priority of the workers is (OS-wise), as long as they do not interfere with other high-priority real-time tasks. On Sat, Apr 1, 2023 at 6:27 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > The network API (sockets etc) will be called by the user's task. > > The network driver will run on the LP worker. > > The socket calls run at the user priority, but no not actually do the > transfers. The just set up to do the transfer then wait for the > transfer to complete. > > The transfer itself is initiated by the driver when there are buffers > and hardware resources available to do the transfer. So the whole > transfer runs on the LP work thread. The user thread is not involved > since it is just waiting all this time. > > Other network actions (like most IOCTLs) are performed entirely on the > user thread. > > > Is there any limitation anywhere that dictates the relationship between > > these two priorities? > Since they run synchronously and generally don't overlap in time, I > would say that the answer is no > >> In a properly turned real time system, you should never have two tasks > >> with the same priority. That breaks some of the fundamental assumptions > >> that support deterministic response times. If two tasks, A and B, have > >> the same priority, the response time of B will be scrambled, depending > >> on if A is running or not and how close A is to releasing the CPU to > >> allow B to run. > > I think this shouldn't be an issue. Tasks with actual real-time > > requirements are at higher and distinct priorities. > > Everything else is at (or around) 100 with a round-robin policy. There > are > > no dead-lines to meet there, so I don't > > care about any jitter. > > > > Also there are two workers in the LP queue, not one. > > So far I haven't noticed any availability issues, but something that > looks > > more like a dead-lock to me. > > Yes, this is only for tasks with real time requirements. There should > be an segregation of priorities into two groups: All of the background > tasks that just need to do things as time permits should be in the lower > priority group. All task that have deadlines to meet should be in a > separate group of with higher priorities. > > That way, then non-real-time background tasks will not interfere with > real time behavior. > > Linux does that: All of the SCHED_OTHER tasks are lower priority than > any of the SCHED_FIFO tasks. > >
