Re: request to nuke gx(4)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:-On [20051002 20:52], Chris Pressey (cpressey@xxxxxxxxxxxxxxx) wrote:
:>Try 'man 4 polling' on any 4.11 machine.  There's a mention there.
:
:Ah.  Ok, regardless of the polling 4.11 still kicked 6's butt with polling.
:
:>btw, ooc, who is "someone" and do they have any plans to measure NetBSD
:>as well?
:
:A guy on the #FreeBSD channel on Undernet.
:I asked, but I am unsure which NetBSD to ask.  2.0.2 is nice, but 3 has
:Release Candidates out and should be focused on I think.
:
:-- 
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
:

    Both FreeBSD's and our DEVICE_POLLING support is based on the hardclock.

    I am not really a fan of device polling, but one thing that we could do
    that would really differentiate us from FreeBSD and make the device
    polling work the way its supposed to would be to separate the polling
    frequency from the hardclock.

    It turns out that we happen to already have a mechanism, called
    SYSTIMERS (which our hardclock uses BTW) which can be used to 
    independantly schedule the polling frequency and even allow it to be
    changed on the fly with a sysctl.  It would be considerably more 
    difficult for FreeBSD to separate their's since they do not have an 
    equivalent systimer mechanism.  I have already separated a number of
    periodic functions, such as the scheduler clock, from the original
    'hardclock'.  I have not separated the networking polling function yet.

    Would someone like to take on a mini project to make this fix?  Your
    starting point would be /usr/src/sys/kern/kern_clock.c.  Read the code,
    understand how the systimers are used for hardclock(), statclock(),
    schedclock(), and so forth, understand how the current DEVICE_POLLING
    hooks work (look for 'DEVICE_POLLING' in that source file), and then
    do a two-step:

    (1) Recode it to use its own systimer.

    (2) Add a sysctl to allow the frequency to be changed on the fly.
	The polling function you install as the systimer could detect
	that the frequency has been changed and reschedule the periodic
	systimer with the new frequency.

    That would give us slam-bang polling support that would be independant
    of our main 'hz'.  We would not have to do the (silly thing) FreeBSD
    does by continually increasing 'hz' to accomodate particular subsystems.

    I think that this is a very doable mini-project for anyone who has 
    messed with the kernel code a little.  There is nothing difficult about
    it.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>