> Don't you think it would be useful to have some reserved memory for
> the netconsole use ?
> It would be nice to have a guarantee that messages are sent over
> network even if the system is under real OOM.
yep, that is very useful indeed.
i've implemented a private emergency pool of 32 packets that we try to
keep filled as much as possible, and which one we use only if GFP_ATOMIC
fails. The new patch can downloaded from:
http://redhat.com/~mingo/netconsole-patches/netconsole-2.4.10-B1
the patch also includes Andrew Morton's suggestion to add the
HAVE_POLL_CONTROLLER define for easier network-driver integration. The
eepro100.c changes now use this define.
the new utilities-tarball is at:
http://redhat.com/~mingo/netconsole-patches/netconsole-client-20010927.tar.gz
this includes Andreas Dilger's netconsole-server script. (i've done a
minor modification to the script, it insmods the netconsole module with
the parameters.)
there is one more thing we could do: we could also allocate the skb on
stack in extreme cases. This adds noticeable latency though, since the skb
xmit has to be polled for completion as well [this can be done with the
current ->poll_controller() method], but this way the netconsole could be
self-sufficient and would be completely independent of the VM.
reports, suggestions, comments welcome,
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/