decreasing interrupt CPU load

[Jason Stone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> If you look at http://info.iet.unipi.it/~luigi/polling, the last Q & A
> question suggests why it is disabled for SMP.  It seems that polling
> only runs on one thread whereas an smp box might handle concurrently
> interupts from different devices.
>
> Can the scheduler move the thread to another cpu or is it locked on a
> particular cpu?

thanks for the pointer.  it seems to me that the thread doing the polling
could move from cpu to cpu, but that's not the issue - the issue, if I'm
understanding the author, is that the polling thread will always be a
single thread, whereas if we use traditional interrupts, they can be
handled on multiple cpu's concurrently.  so interrupts, with multiple
cpu's to handle them, might give much better performance than a single
polling thread.

if that's the only issue, then preventing one from compiling with both SMP
and DEVICE_POLLING doesn't seem necesary, since you can turn polling on
and off at runtime with sysctl's.

luigi: does that sound right to you?  has any consideration been giving to
removing the restriction preventing DEVICE_POLLING from building on an SMP
system, in light of the fact that polling can just be turned off if it's
giving suboptimal performance?


 -Jason

 --------------------------------------------------------------------------
 Freud himself was a bit of a cold fish, and one cannot avoid the suspicion
 that he was insufficiently fondled when he was an infant.
	-- Ashley Montagu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQFBeB95swXMWWtptckRAvlRAJ4806zyUOwMq89qgNKXlbbOE826LQCg6AGW
qWDj3u/F4V3a51YJQAA2qpM=
=sN26
-----END PGP SIGNATURE-----