On Wed, Aug 19, 2020 at 12:10:12PM +0200, Martin Pieuchot wrote: > On 18/08/20(Tue) 15:30, Visa Hankala wrote: > > On Tue, Aug 18, 2020 at 11:04:47AM +0200, Martin Pieuchot wrote: > > > Diff below changes the order of operations in kqueue_register() to get > > > rid of an unnecessary pool_get(). When an event is already present on > > > the list try to acquire it first. Note that knote_acquire() may sleep > > > in which case the list might have changed so the lookup has to always > > > begin from the start. > > > > > > This will help with lazy removal of knote in poll/select. In this > > > scenario EV_ADD is generally always done with an knote already on the > > > list. > > > > Some of the overhead could be absorbed by using a pool cache, as shown > > in the diff below. However, I am not suggesting that the cache should > > be taken into use right now. The frequency of knote pool usage is > > relatively low currently; there are other pools that would benefit more > > from caching. > > Agreed, this is a nice idea to revisit. Do you have a way to measure > which pool could benefit from caches?
I think systat(1)'s pool view gives a starting point. > > A related question is what implications the increased use of the pool > > cache feature would have under memory pressure. > > Do you have suggestion on how to measure this as well? Could dt(4) > probes or evtcount() help us? I do not have a specific tool in mind, just a vague question: "Can the system start to perform poorly more easily than before?" However, only experimentation will tell.
