Le Sat, Jun 03, 2023 at 01:23:38AM +0000, Joel Fernandes a écrit : > On Wed, May 31, 2023 at 12:17:31PM +0200, Frederic Weisbecker wrote: > > The lazy and the regular bypass queues share the same thresholds in > > terms of number of callbacks after which a flush to the main list is > > performed: 10 000 callbacks. > > > > However lazy and regular bypass don't have the same purposes and neither > > should their respective thresholds: > > > > * The bypass queue stands for relieving the main queue in case of a > > callback storm. It makes sense to allow a high number of callbacks to > > pile up before flushing to the main queue, especially as the life > > cycle for this queue is very short (1 jiffy). > > Sure. > > > > > * The lazy queue aims to spare wake ups and reduce the number of grace > > periods. There it doesn't make sense to allow a huge number of > > callbacks before flushing so as not to introduce memory pressure, > > especially as the life cycle for this queue is very long (10 > > seconds). > > It does make sense as we have a shrinker, and it is better to avoid RCU > disturbing the system unwantedly when there's lots of memory lying around. > > > > > For those reasons, set the default threshold for the lazy queue to > > 100. > > I am OK with splitting the qhimark, but this lazy default is too low. In > typical workloads on ChromeOS, we see 1000s of callback even when CPU > utilization is low. So considering that, we would be flushing all the time. > > Eventually I want the mm subsystem to tell us when flushing is needed so we > could flush sooner at that time if really needed, but for now we have a > shrinker so it should be OK. Is there a reason the shrinker does not work for > you? So you mean dynamically adapting the lazy qhimark on top of shrinker calls, right? That would make sense indeed. Thanks.
