Hi, Thomas, Thanks for your reply! I replied below. On 3/11/2024 3:12 PM, Thomas Gleixner wrote: > On Mon, Mar 11 2024 at 11:25, Joel Fernandes wrote: >> On 3/11/2024 1:18 AM, Ankur Arora wrote: >>>> Yes, I mentioned this 'disabling preemption' aspect in my last email. My point >>>> being, unlike CONFIG_PREEMPT_NONE, CONFIG_PREEMPT_AUTO allows for kernel >>>> preemption in preempt=none. So the "Don't preempt the kernel" behavior has >>>> changed. That is, preempt=none under CONFIG_PREEMPT_AUTO is different from >>>> CONFIG_PREEMPT_NONE=y already. Here we *are* preempting. And RCU is getting on >>> >>> I think that's a view from too close to the implementation. Someone >>> using the kernel is not necessarily concered with whether tasks are >>> preempted or not. They are concerned with throughput and latency. >> >> No, we are not only talking about that (throughput/latency). We are also talking >> about the issue related to RCU reader-preemption causing OOM (well and that >> could hurt both throughput and latency as well). > > That happens only when PREEMPT_RCU=y. For PREEMPT_RCU=n the read side > critical sections still have preemption disabled. Sorry, let me clarify. And please forgive my noise but it is just a point of view. CONFIG_PREEMPT_AUTO always preempts sooner or later, even for preempt=none. A point of view could be, if you are preempting anyway (like CONFIG_PREEMPT=y), then why bother with disabling CONFIG_PREEMPT_RCU or even give it as an option. After all, with CONFIG_PREEMPT=y, you cannot do CONFIG_PREEMPT_RCU=n. It is just a point of view, while we are still discussing this patch series ahead of its potential merge. >> With CONFIG_PREEMPT_AUTO=y, you now preempt in the preempt=none mode. Something >> very different from the classical CONFIG_PREEMPT_NONE=y. > > In PREEMPT_RCU=y and preempt=none mode this happens only when really > required, i.e. when the task does not schedule out or returns to user > space on time, or when a higher scheduling class task gets runnable. For > the latter the jury is still out whether this should be done or just > lazily defered like the SCHED_OTHER preemption requests. > > In any case for that to matter this forced preemption would need to > preempt a RCU read side critical section and then keep the preempted > task away from the CPU for a long time. > > That's very different from the unconditional kernel preemption model which > preempt=full provides and only marginally different from the existing > PREEMPT_NONE model. I know there might be dragons, but I'm not convinced > yet that this is an actual problem. Sure it is less aggressive than a full preemption, still a preemption nonetheless, so its quirky in the regard of whether or not RCU preemption is provided as an option (as I mentioned as a point-of-view above). > OTOH, doesn't PREEMPT_RCU=y have mechanism to mitigate that already? It does. But that sounds more in favor of forcing PREEMPT_RCU=y for AUTO since such mitigation will help those concerns that AUTO users would need PREEMPT_RCU=y (?). >> Essentially this means preemption is now more aggressive from the point of view >> of a preempt=none user. I was suggesting that, a point of view could be RCU >> should always support preepmtiblity (don't give PREEEMPT_RCU=n option) because >> AUTO *does preempt* unlike classic CONFIG_PREEMPT_NONE. Otherwise it is >> inconsistent -- say with CONFIG_PREEMPT=y (another *preemption mode*) which >> forces CONFIG_PREEMPT_RCU. However to Paul's point, we need to worry about those >> users who are concerned with running out of memory due to reader >> preemption. > > What's wrong with the combination of PREEMPT_AUTO=y and PREEMPT_RCU=n? > Paul and me agreed long ago that this needs to be supported. There's nothing wrong with it. Its just a bit quirky (again just a point of view), that for a configuration that causes preemption (similar to CONFIG_PREEMPT=y), that PREEMPT_RCU can be disabled. After all, again with CONFIG_PREEMPT=y, PREEMPT_RCU cannot be currently disabled. >> In that vain, maybe we should also support CONFIG_PREEMPT_RCU=n for >> CONFIG_PREEMPT=y as well. There are plenty of popular systems with relatively >> low memory that need low latency (like some low-end devices / laptops >> :-)). > > I'm not sure whether that's useful as the goal is to get rid of all the > CONFIG_PREEMPT_FOO options, no? I think I may have lost you here, how does forcing or not forcing CONFIG_PREEMPT_RCU relate to getting rid of CONFIG options? There's no new CONFIG options added one way or the other. > I'd rather spend brain cycles on figuring out whether RCU can be flipped > over between PREEMPT_RCU=n/y at boot or obviously run-time. Yes I agree with that actually, and I see Paul provided some detailed thoughts in a reply to you in your quest to get him to write a novel as you put it ;-). I am Ok with our providing preemptible-RCU as an option with AUTO and it could be documented well that this is possible. I am fully on board also with the sentiment of getting rid of the zoo of CONFIG_PREEMPT options! thanks, - Joel
