On 07/02/17(Tue) 11:03, Mike Belopuhov wrote:
> On 7 February 2017 at 10:13, Martin Pieuchot <m...@openbsd.org> wrote:
> > On 06/02/17(Mon) 17:19, Mike Belopuhov wrote:
> >> On 6 February 2017 at 17:02, Martin Pieuchot <m...@openbsd.org> 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.
