svn commit: r243631 - in head/sys: kern sys
Alfred Perlstein
bright at mu.org
Mon Jan 14 16:16:13 UTC 2013
On 1/14/13 10:09 AM, Andre Oppermann wrote:
> On 13.01.2013 19:06, Alfred Perlstein wrote:
>> On 1/12/13 10:32 PM, Adrian Chadd wrote:
>>> On 12 January 2013 11:45, Alfred Perlstein <bright at mu.org> wrote:
>>>
>>>> I'm not sure if regressing to the waterfall method of development
>>>> is a good
>>>> idea at this point.
>>>>
>>>> I see a light at the end of the tunnel and we to continue to just
>>>> handle
>>>> these minor corner cases as we progress.
>>>>
>>>> If we move to a model where a minor bug is grounds to completely
>>>> remove
>>>> helpful code then nothing will ever get done.
>>>>
>>> Allocating 512MB worth of callwheels on a 16GB MIPS machine is a
>>> little silly, don't you think?
>>>
>>> That suggests to me that the extent of which maxfiles/maxusers/etc
>>> percolates the codebase wasn't totally understood by those who wish to
>>> change it.
>>>
>>> I'd rather see some more investigative work into outlining things that
>>> need fixing and start fixing those, rather than "just change stuff and
>>> fix whatever issues creep up."
>>>
>>> I kinda hope we all understand what we're working on in the kernel a
>>> little better than that.
>>
>> Cool! I'm glad people are now aware of the callwheel allocation
>> being insane with large maxusers.
>>
>> I saw this about a month ago (if not longer), but since there were
>> half a dozen people calling me an
>> imbecile who hadn't really yet read the code I didn't want to inflame
>> them more by fixing that with
>> "a hack". (actually a simple fix).
>>
>> A simple fix is to clamp callwheel size to the previous result of a
>> maxusers of 384 and call it a day.
>>
>> However the simplicity of that approach would probably inflame too
>> many feelings so I am unsure as
>> how to proceed.
>>
>> Any ideas?
>
> I noticed the callwheel dependency as well and asked mav@ about it
> in a short email exchange. He said it has only little use and goes
> away with the calloutng import. While that is outstanding we need
> to clamp it to a sane value.
>
> However I don't know what a sane value would be and why its size is
> directly derived from maxproc and maxfiles. If there can be one
> callout per process and open file descriptor in the system, then
> it probably has to be so big. If it can deal with 'collisions'
> in the wheel it can be much smaller.
>
If it really goes away with calloutng, then we should probably leave it
be in -current.
As far as clipping it when/if we push maxusers fixes in -stable (which
we must do) then my impression (although maybe wrong) is that the
callwheels (cc_callwheel) are just arrays of hash buckets based on what
tick will be fired next MOD callwheelmask. This means that if
cc_callwheel is way too small, then we will wind up with collisions,
however if it's enormous then we wind up with a window that is so large
it can accommodate something like hundreds of ticks into the future.
Example:
> Loaded symbols for /boot/kernel/profile.ko
> #0 sched_switch (td=0xffffffff81373e40, newtd=0xfffffe001aab5960,
> flags=<value optimized out>) at ../../../kern/sched_ule.c:1954
> 1954 cpuid = PCPU_GET(cpuid);
> (kgdb) p callwheelsize
> $1 = 2097152
> Current language: auto; currently minimal
> (kgdb) # .(16:06:31)(root at dan)
> /usr/home/alfred # sysctl -a | grep hz
> kern.clockrate: { hz = 1000, tick = 1000, profhz = 8128, stathz = 127 }
> kern.dcons.poll_hz: 25
> kern.hz: 1000
> debug.psm.hz: 20
> .(16:06:37)(root at dan)
> /usr/home/alfred # 2097152
> .(16:06:40)(root at dan)
> /usr/home/alfred # bc
> 2097152 / 1000
> 2097
> ^D# .(16:06:56)(root at dan)
> /usr/home/alfred # sysctl kern.maxusers
> kern.maxusers: 3406
So basically on this box there are enough callwheel slots for something
like 2097 seconds, or 34 minutes into the future.
I would assume that a machine that was capped at 384 maxusers would wind
up with something that could handle callouts up to ~3 minutes in the
future without wraparound and collisions.
As far as the ncallout, that is for timeout(9) support. At a glance I'm
not aware of any users of timeout(9) that are not "per device" so
there's unlikely to be a need for a timeout(9) supporting pre-allocated
timeout per prorcess/file, more likely something like N-devices*4, which
is fine at something way lower than the max allocated at 384 maxusers
from before all the changes we have made.
I could be wrong.. but I still believe that it would be quite the system
that would need more than
callout=get_callout_from_maxusers(min(maxusers, 384));
Functions calling this function: timeout
Functions calling this function: timeout
File Function Line
0 si.c si_start 1439 pp->lstart_ch =
timeout(si_lstart, (caddr_t)pp, time);
1 sio.c siobusycheck 1269
timeout(siobusycheck, com, hz / 100);
2 sio.c siopoll 1744
timeout(siobusycheck, com, hz / 100);
3 sio.c siosettimeout 2203 sio_timeout_handle
= timeout(comwakeup, (void *)NULL,
4 sio.c comwakeup 2220 sio_timeout_handle
= timeout(comwakeup, (void *)NULL, sio_timeout);
5 syscons.c scrn_timer 1834
timeout(scrn_timer, sc, hz / 10);
6 syscons.c scrn_timer 1884
timeout(scrn_timer, sc, hz / 10);
7 syscons.c scrn_timer 1902
timeout(scrn_timer, sc, hz / 25);
8 syscons.c blink_screen 3847
timeout(blink_screen, scp, hz / 10);
9 trm.c trm_ExecuteSRB 478
ccb->ccb_h.timeout_ch = timeout(trmtimeout, (caddr_t)srb,
(ccb->ccb_h.timeout * hz) / 1000);
a tws_cam.c tws_execute_scsi 782 ccb_h->timeout_ch
= timeout(tws_timeout, req, (ccb_h->timeout * hz)/1000);
b tws_cam.c tws_send_scsi_cmd 820 req->thandle =
timeout(tws_timeout, req, (TWS_IO_TIMEOUT * hz));
c tws_cam.c tws_set_param 867 req->thandle =
timeout(tws_timeout, req, (TWS_IOCTL_TIMEOUT * hz));
d tws_services.c tws_print_stats 398
timeout(tws_print_stats, sc, 300*hz);
e if_wl.c wlstart 1022 sc->watchdog_ch =
timeout(wlwatchdog, sc, 10);
f spic.c spictimeout 429 sc->sc_timeout_ch
= timeout(spictimeout, sc, spic_pollrate);
g spic.c spictimeout 442 sc->sc_timeout_ch
= timeout(spictimeout, sc, spic_pollrate);
h spic.c spicopen 459
timeout(spictimeout, sc, spic_pollrate);
i kern_cons.c sysbeep 624
timeout(sysbeepstop, (void *)NULL, period);
j kern_fail.c fail_point_sleep 133
timeout(fp->fp_sleep_fn, fp->fp_sleep_arg, timo);
k aarp.c aarptimer 128 aarptimer_ch =
timeout(aarptimer, NULL, AARPT_AGE * hz);
l aarp.c aarptnew 580 aarptimer_ch =
timeout(aarptimer, (caddr_t)0, hz);
m ng_btsocket_l2cap.c ng_btsocket_l2cap_timeout 2663 pcb->timo =
timeout(ng_btsocket_l2cap_process_timeout, pcb,
n ng_btsocket_rfcomm.c ng_btsocket_rfcomm_timeou 3449 pcb->timo =
timeout(ng_btsocket_rfcomm_process_timeout, pcb,
o ng_fec.c ng_fec_init 642 priv->fec_ch =
timeout(ng_fec_tick, priv, hz);
p ng_fec.c ng_fec_tick 717 priv->fec_ch =
timeout(ng_fec_tick, priv, hz);
q key.c key_timehandler 4551 (void
)timeout((void *)key_timehandler, (void *)0, hz);
r key.c key_init 7776 timeout((void
*)key_timehandler, (void *)0, hz);
s ncp_subr.c ncp_init 107 ncp_timer_handle =
timeout(ncp_timer, NULL, NCP_TIMER_TICK);
t fdc.c fd_turnon 1186
timeout(fd_motor_on, fd, hz);
u fdc.c fdstate 1786 fd->toffhandle =
timeout(fd_turnoff, fd, 4 * hz);
v fdc.c fdstate 1877
timeout(fd_pseudointr, fdc, hz / 16);
w fdc.c fdstate 2092 fd->tohandle =
timeout(fd_iotimeout, fdc, hz);
x fdc.c fdstate 2101 fd->tohandle =
timeout(fd_iotimeout, fdc, hz);
y fdc.c fdstate 2218
timeout(fd_pseudointr, fdc, hz / 8);
* Lines 71-106 of 115, 10 more - press the space bar to display more *
Functions calling this function: timeout
File Function Line
0 olpt.c lptopen 421 timeout (lptout,
(caddr_t)sc,
1 olpt.c lptout 440 timeout (lptout,
(caddr_t)sc, sc->sc_backoff);
2 pckbd.c pckbd_timeout 260
timeout(pckbd_timeout, arg, hz/10);
3 sio.c sioattach 2012
timeout(siobusycheck, com, hz / 100);
4 sio.c sioattach 2696
timeout(siobusycheck, com, hz / 100);
5 sio.c sioattach 3330 sio_timeout_handle
= timeout(comwakeup, (void *)NULL,
6 sio.c sioattach 3347 sio_timeout_handle
= timeout(comwakeup, (void *)NULL, sio_timeout);
7 sio.c sioattach 3933
timeout(pc98_check_msr, (caddr_t)dev,
8 sio.c sioattach 3951
timeout(pc98_check_msr, (caddr_t)dev,
9 ncr.c ncr_timeout 5171 timeout
(ncr_timeout, (caddr_t) np, step ? step : 1);
* Press the space bar to display the first lines again *
-Alfred
More information about the svn-src-head
mailing list