Re: taskqueue for pf periodic events

Gleb,

On Tuesday 07 March 2006 11:59, Gleb Smirnoff wrote:
running a pf load balancer I have noticed that the "swi4: clock"
process consumes a noticable amount of CPU time, when a lot of
states are purged from pf cache. The load balancer is also running
CARP, and a hot spare is working here too. Reading daily run outputs
from the second router, I have noticed that a few times per day
the redundant router preempts the main one, since it doesn't
receive announcement in time from master. So, I had a theory that
a heavy pf purge is running so long, that a CARP announcement
is delayed. You know, all callout(9) events are serialized in one
thread - "swi4: clock".

So I made a patch that moves all periodic pf(4) job into separate
context. The patch uses new taskqueue API made by Scott. I have
ported the API to RELENG_6 and made my patch for RELENG_6. I've
been running the patch for 27 days and the spurious preemtions
of CARP backup had gone away. No problems were noticed. The box
is running SMP kernel on a single CPU box with HTT (2 logical
CPUs), HTT enabled.

The patch attached.

Makes sense to me. I recall that we talked about this problem before and I
think I even sent you a patch to expire only a fixed amount of states at
once. Can't find that patch now, do you remember? OpenBSD has by now done
something along those lines and I will import it as soon as 3.9 is ready and
I have some time. Could you change the purge part to a kernel thread like
done in OpenBSD:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c#rev1.498

I'm not sure which is better, but staying close to the OpenBSD sollution would
certainly make my life easier.

Thanks for coming up with this!

--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: pgpQhMJScQfZq.pgp
Description: PGP signature

Relevant Pages

  • Re: RT patch acceptance (scheduler)
    ... > lock up the CPU in IRQ mode for human-perceptible time, ... For non-DMA IDE access data copies are CPU driven ... which can create tons of latency problems for that case. ... I suggest that you read the patch for the answer to softirq ...
    (Linux-Kernel)
  • Re: better wake-balancing: respin
    ... >>I guess I missed the objection for dropping the patch. ... correlation between the CPU the interrupt arrives on and the CPU the ... There is no point in immediate balancing either: ... If this patch hurts other workloads (and please ...
    (Linux-Kernel)
  • Re: Intel DG31PR and RTL8168/8111 issue
    ... The previous patch you used may have problems on multicast filtering. ... CPU supports Enhanced Speedstep, ... <ACPI PCI bus> on pcib0 ... hwrev = 38400000 ...
    (freebsd-stable)
  • Re: [PATCH] AMD Thermal Interrupt Support
    ... I'll add a robust description with the next revision of the patch. ... My buddy at Google suggested that I might as well fix this while I'm ... the throttling MCEs which you might naturally expect to see ... if you're expecting to be warned at 50C that your CPU has ...
    (Linux-Kernel)
  • Re: better wake-balancing: respin
    ... >>a patch may not be the right way to go. ... > correlation between the CPU the interrupt arrives on and the CPU the ... There is no point in immediate balancing either: ... > in such a workload, my patch will clearly improve things, by not ...
    (Linux-Kernel)