Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jul 2017 10:15:30 +0200
From:      Hans Petter Selasky <hps@selasky.org>
To:        Sebastian Huber <sebastian.huber@embedded-brains.de>, FreeBSD <freebsd-hackers@freebsd.org>
Subject:   Re: Relationship between ncallout and callwheelsize
Message-ID:  <6453f4fa-016f-3d7a-ce03-aa49c7f465e5@selasky.org>
In-Reply-To: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de>
References:  <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 07/20/17 08:59, Sebastian Huber wrote:
> Hello,
> 
> I noticed on a LPC4088 running at 96MHz from external SDRAM that the 
> callout_process() function needs a lot of time even if no callouts are 
> active. The reason is that on a 32-bit architecture with only 13 general 
> purpose registers this function needs a lot of load/store operations. So 
> I tried to reduce the complexity by using compile time constants. I 
> don't understand why the callwheelsize and the timeout(9) 
> pre-allocations are related:
> 
>      ncallout = imin(16 + maxproc + maxfiles, 18508);
>      TUNABLE_INT_FETCH("kern.ncallout", &ncallout);
> 
>      /*
>       * Calculate callout wheel size, should be next power of two higher
>       * than 'ncallout'.
>       */
>      callwheelsize = 1 << fls(ncallout);
>      callwheelmask = callwheelsize - 1;
> 
> The size of the wheel should be related to typical timeout values to 
> balance memory size and hash collisions. Why is there a connection to 
> the timeout(9) pre-allocations?
> 

Hi,

The calloutwheel is simply an optimisation. If you don't need many 
callouts, maybe a per-CPU list will be enough for your purpose.

--HPS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6453f4fa-016f-3d7a-ce03-aa49c7f465e5>