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 <bri...@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@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@dan)
/usr/home/alfred # 2097152
.(16:06:40)(root@dan)
/usr/home/alfred # bc
2097152 / 1000
2097
^D# .(16:06:56)(root@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"