Giant-free polling [PATCH]

[Gleb Smirnoff]

On Fri, Mar 11, 2005 at 07:44:48AM -0800, Luigi Rizzo wrote:
L> while i am happy to see interest on having this supported, and while
L> I understand the excitement in firing the editor and writing code,
L> i don't think this approach of hacking up some patch that allows
L> multiple poll* instances to run without panicing the box, or
L> discussing the performance of lists vs arrays vs IFF_* flags will
L> lead to anything.
L> 
L> As I asked this already, consider this msg a rant, for archival
L> purposes, calling for a sane approach to the problem.
L> 
L> Polling in the UP case is beneficial because it has some features
L> listed e.g. in
L> 
L> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=128950+0+/usr/local/www/db/text/2005/freebsd-net/20050306.freebsd-net
L> 
L> For the SMP case there are the basic issues to handle (proper locking,
L> preventing deadlocks) but also performance issues e.g. to avoid
L> that multiple polling instances just fight for the lock but do
L> nothing useful, see e.g. the case described in
L> 
L> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=71980+0+/usr/local/www/db/text/2005/freebsd-net/20050306.freebsd-net
L> 
L> 
L> Now, if you want to approach the issue seriously, you need to:
L> 
L> 1) _design_ a locking strategy for SMP polling -- design meaning
L>    provide a description in english, even a sketchy one,
L>    which will eventually end up in a manpage such as polling(4),
L>    or in the source file as a comment.
L>    Certainly a design is not C code or patches without comments from which
L>    one should figure out the overall picture.
L> 
L> 2) evaluate how the design compares in terms of features (e.g. those listed
L>    in the first reference above) to the UP case. I am not
L>    saying one should implement all of them, but at least it must
L>    be clear how the two things are different, if they are.
L> 
L> 3) evaluate how the design addresses (in terms of performance)
L>    the contention problems, of which the second reference above is
L>    probably just one but at least a very obvious one;
L> 
L> 4) implement it -- and if you want it to be reviewed, please post
L>    the full code, not just differences -- the code will be terribly
L>    different to be human readable in terms of a diff;
L> 
L> 5) optimise it -- e.g. deal with arrays vs lists, implicit vs
L>    explicit flags, etc.
L> 
L> It seems to me that this whole discussion is proceding from step 4
L> and ignoring the first 3 steps. Please, step back from your keyboards
L> and move to the whiteboard, if nothing else to prove me that you
L> have already addressed all the issues.

Luigi,

at this moment we are doing step 0 - removing Giant lock from polling,
to make its locking independent from other Giant-locked subsystems.
There is no code for SMP polling yet, and we will take into account all
what you say as soon as we approach SMP polling.

In both our patches polling logic and implementation is not touched, it is
only surrounded with locking.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE