On Mon, Feb 06, 2023 at 10:42:46AM +0100, Christoph Lameter wrote: > On Fri, 3 Feb 2023, Marcelo Tosatti wrote: > > > > Isnt there some lock/serializtion to stall the kernel until you are done? > > > > Not that i know of. Anyway, an additional datapoint is: > > > > "Software defined PLC" > > (https://www.redhat.com/en/blog/software-defined-programmable-logic-controller-introduction), > > applications > > can perform system calls in their time sensitive loop. > > > > One example of an opensource software is OpenPLC. > > > > One would like to avoid interruptions for those cases as well. > > Well allowing sytem calls during "time sensitiveness" implies > it is not that sensitive to vmstat updates > which have a smaller impact than system calls. Not necessarily. Certain system calls won't touch per-CPU vmstats: nanosleep, for example. Perhaps i misunderstood your suggestion: So the patchset in discussion uses (or should use, in v2), in both vmstat_shepherd and vmstat counter modification, LOCK CMPXCHG. There is the potential that LOCK CMPXCHG, from vmstat counter modification, incurs a performance degradation. Note however, that cachelocking should hopefully "hide" the costs. Do you have any concerns about this patchset other than the performance degradation due to addition of LOCK in CMPXCHG? The other possible concern is that the preempt-disabled functions, namely: __inc_node_page_state, __dec_node_page_state, __mod_node_page_state, __inc_zone_page_state, __dec_zone_page_state, __mod_zone_page_state have been switched to cmpxchg loop. Is that a problem? Would expect that measuring LOCK CMPXCHG does not incur significant performance degradation as compared to CMPXCHG (from the page allocation benchmark) would address your concerns? Thanks
