[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/44473: (FAST-)IPSEC processing comsumes too much CPU in interrupt processing
The following reply was made to PR kern/44473; it has been noted by GNATS.
From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Subject: Re: kern/44473: (FAST-)IPSEC processing comsumes too much CPU in
Date: Thu, 27 Jan 2011 10:58:55 -0500
On Thu, 27 Jan 2011 13:00:01 +0000 (UTC)
> - no upper limit for the number of threads - an easy aproach may be the
> number of CPU's available
> - curently the threads are not bound to a CPU, they switch between
> them. But I simple do not know how to fix them to a
> CPU and I'm not shure how to decide to which CPU it should be bound.
I'm not sure if others will agree but perhaps that a default or limit
of one or two thread(s) per CPU would be allright. For tieing those
threads to specific CPUs, in userland there's AFFINITY(3) for that,
which internally uses the _sched_setaffinity(2) syscall,
sys__sched_setaffinity() in src/sys/kern/sys_sched.c which sets the
flag and ties a cpuset with the lwp. That syscall obviously doesn't
allow to do this on system threads, but it could be from a security
standpoint rather than a limit of the system threads capabilities.
Main Index |
Thread Index |