Remaining non-MPSAFE netisr handlers


Dear all:

In the continuing campaign to eliminate the Giant lock from the dregs of the network stack, I thought I'd send out a list of non-MPSAFE netisr handlers:

Location Handler Removed with IFF_NEEDSGIANT
dev/usb/usb_ethersubr.c:120 usbintr Yes
net/if_ppp.c:277 pppintr Yes
netinet6/ip6_input.c ip6_input No

The plan for 8.0 is to remove the NETISR_MPSAFE flag -- all netisr handlers will be executed without the Giant lock. This doesn't prohibit acquiring Giant in the handler if required, although that's undesirable for the obvious reasons (potentially stalling interrupt handling, etc). Obviously, what would be most desirable is eliminating the remaining requirement for Giant in the IPv6 input path, primarily consisting of mld6 and nd6.

With this in mind, my current plan is to remove the flag and add explicit Giant acquisition for any remaining handlers in June when IFF_NEEDSGIANT device drivers are disabled.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Remaining non-MPSAFE netisr handlers
    ... The plan for 8.0 is to remove the NETISR_MPSAFE flag -- all netisr handlers will be executed without the Giant lock. ... my current plan is to remove the flag and add explicit Giant acquisition for any remaining handlers in June when IFF_NEEDSGIANT device drivers are disabled. ...
    (freebsd-net)
  • Re: Remaining non-MPSAFE netisr handlers
    ... On Mon, 26 May 2008, Robert Watson wrote: ... The plan for 8.0 is to remove the NETISR_MPSAFE flag -- all netisr handlers will be executed without the Giant lock. ... This doesn't prohibit acquiring Giant in the handler if required, although that's undesirable for the obvious reasons. ... my current plan is to remove the flag and add explicit Giant acquisition for any remaining handlers in June when IFF_NEEDSGIANT device drivers are disabled. ...
    (freebsd-arch)
  • Re: Remaining non-MPSAFE netisr handlers
    ... On Mon, 26 May 2008, Robert Watson wrote: ... The plan for 8.0 is to remove the NETISR_MPSAFE flag -- all netisr handlers will be executed without the Giant lock. ... This doesn't prohibit acquiring Giant in the handler if required, although that's undesirable for the obvious reasons. ... my current plan is to remove the flag and add explicit Giant acquisition for any remaining handlers in June when IFF_NEEDSGIANT device drivers are disabled. ...
    (freebsd-net)
  • Re: Plans about GIANT-LOCK, SMP performance ...
    ... One of the single largest projects associated with the FreeBSD 5.x release ... line has been the elimination of the Giant lock from many of the kernel ... infrastructure necessary to remove Giant from major subsystems, ... network subsystem, and the storage subsystem. ...
    (freebsd-questions)
  • Re: Giant-free ahc?
    ... > *Giant showed up a lot when running top for processes accessing data on ... It could be a GIANT lock for some other resource of ... increasing the chances of Giant contention being observed ... Patches to reduce the use of Giant in sysctlwere recently ...
    (freebsd-current)