On 7 February 2017 at 11:14, Martin Pieuchot <[email protected]> wrote: > On 07/02/17(Tue) 11:03, Mike Belopuhov wrote: >> On 7 February 2017 at 10:13, Martin Pieuchot <[email protected]> wrote: >> > On 06/02/17(Mon) 17:19, Mike Belopuhov wrote: >> >> On 6 February 2017 at 17:02, Martin Pieuchot <[email protected]> wrote: >> >> > PF has its own home-brewed solution for dealing with CPU hogging. It >> >> > has been introduced in r1.88 of net/pf_table.c and I couldn't find any >> >> > explanation why it is different than the idiom we use in other places. >> >> > >> >> >> >> The idea was just to be able to load a huge table semi-efficiently. >> > >> > Can you explain what you mean with semi-efficiently? >> > >> >> you'd yield too much as far as i understand. try loading those >> monster spamd tables on apu/soekris and see if there's a >> noticeable slowdown. > > I'm not sure to understand what do you mean with "too much" nor in which > context it applies. With or without my diff? > > What I know is that my diff introduces fewer context switches, see: > https://marc.info/?l=openbsd-bugs&m=148639395411957&w=2 > > I also know that it kills some magic and makes kernel code consistent. > >> >> I don't think SPCF_SHOULDYIELD existed back then. >> > >> > cvs blame tells me otherwise. >> >> strange, but i can't rule that out. > > I still can't understand why a userland thread should yield after 1024 > insertions. Maybe tedu@ can explain his original intention? IMHO a > thread should yield if it hogs the CPU and that's exactly what my diff > does.
i think it was just chosen empirically. hogging cpu to load table data into the kernel pf table was an acceptable behavior. hogging too much for too long wasn't. 1024 table entries is more than most of tables normal setups have and the rest use huge ones from spamd.
