Re: Fwd: Removing Giant from a driver

usleepless@xxxxxxxxx wrote this message on Sat, Oct 21, 2006 at 00:50 +0200:
what should it look like?

You should be creating a mutex (using mtx_init) at attach time, and
pass that mutex instead of Giant...

and don't touch busdma_lock_mutex? ( i am passing NULL, NULL at the moment )

see bus_dma(9) for more information... but yes, if you use a MTX_DEF
mutex, busdma_lock_mutex is fine...

and how will i prevent the interrupt routine from interfering with
userland operations? can i place a "mtx_lock()" call in the interrupt
routine?

Correct.... Fast interrupt handlers cannot use a sleeping mutex, but
I doubt this driver is using a fast interrupt handler...

what is the benefit of a fast interrupt handler? ( i assume a
taskqueue is involved ). the interrupt-dma-code of this driver
includes tsleep-calls. does that hurt? i have a shared intterupt with
the second tuner-module and my soundcard.

A fast interrupt handler doesn't context switch, is uses the stack
that was currently running, so it can't sleep since the stack it is
running on may be the stack that needs to run to unlock the lock you
would sleep to aquire...

i ask because the performance on my FBSD 6.x, P4 2.4ghz, 1 card, 2
tuners setup dissapoints me compared to my 4.11, P3 1.0ghz(!), 2
cards, 4 tuners setup.

tsleep'ing from an interrupt handler can be really bad... if the
interrupt handler is shared, the other interrupt handler won't run
till the first one returns...

I have no issues w/ performance on my HDTV capture driver... It's
something like 2-5% cpu usage when I capture.. Though I've only ever
tried one card in it...

the 4.11 machine is headless, the 6.x machine has 2 lcds through 1
ati-radeon. it is on the 6.x machine i try to run mythfrontend and use
the card at the same time.

i can imagine this is very complex: the 6.x machine is dealing with:
- capturing video ( using this driver )
- running mythfrontend ( driving XVideo and OSS )
- mythbackend reading from the cxm device, and writing to a NFS-share

this driver is generating about 1 megabyte per second. the 4.11
machine is handling 4 x 1 megabyte per second just fine writing it to
disk, and doing other stuff ( apache, postgresql, hylafax, firewall,
natd, nfs-server, mythbackends ).

is there a howto somewhere?

There are man pages on how to use the various locking primitives, but
it is assumed that you have knowlege of concurrent programming...

i have, i know mutexes, semaphores, critical sections etc. heck, i
implemented 32-bits threading for watson-c on w3.11 once.

i have read http://www.freebsd.org/projects/busdma/
- this driver uses the busdma framework
- i have registered the interrupt INTR_MPSAFE
- SMPng locked: i have employed a mutex instead of spltty()
- p!=a safety: i don't think this is relevant right now

but i lack the connection with the freebsd-kernel. for example: i
don't understand what Giant is good for. i can imagine Giant is

Giant is just one big lock that protects things that aren't properly
locked yet... This lets you serialize parts of the kernel w/o having
to do tons of work figuring out exactly where all the locks should
go... In the 4.x days, the kernel could only be running on one cpu
at a time, the Giant emulates that behavior...

important for a network-interface-driver because of the framework. but
what does the cxm driver has to do with it? is transforming this
driver to use fast-interrupts worthwhile? ( like the if-em driver )

If you are truely MPSAFE, you should not use Giant... Network drivers
only used Giant when they hadn't been locked yet...

You can take a look at books on pthreads and other related
matierals for info on using locks...

If you figure out the licensing issues w/ the firmware, I'll import
the driver into FreeBSD...

i suppose that will never happen:
- hauppauge firmware is needed

Well, there was some work about getting licensing from Hauppauge to let
FreeBSD distribute it... But the original author disappeared, and I
haven't heard anything... I do have a pvr250 card, but what's the
point when I have my HD driver working now? :)

- i used GPLed linux/v4l2 headers and sourefiles to make the pvr150s/500s
work

well, those can go in gnu, and it'd be great if we could make the
driver not require them, though I don't know how integrated the new
work is...

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages