OpenBSD Multimedia Resources List

Links on this page refer to multimedia resources (podcast, vodcast, audio recordings, video recordings, photos) related to OpenBSD or of interest for OpenBSD users.

This list is available as chronological overview, as a tag cloud and via the sources.
This list is also available as RSS feed

If you know any resources not listed here, or notice any dead links, please send details to Edwin Groothuis so that it can be included or updated.

Tag: mp

• EuroBSDCon 2008 - Aggelos Economopoulos - An MP-capable network stack for DragonFlyBSD with minimal use of locks
  Source: EuroBSDCon
  Added: 22 October 2008
  Tags: eurobsdcon, eurobsdcon2008, dragonflybsd, mp, network stack, aggelos economopoulos
  MP3 (1 byte, 42 minutes), OGG (1 byte, 42 minutes), PDF (1 byte, n pages)
  Given the modern trend towards multi-core shared memory multiprocessors, it is inconceivable for production OS kernels not to be reentrant. The typical approach for allowing multiple execution contexts to simultaneously execute in kernel mode has been to use fine-grained locking for synchronising access to shared resources. While this technique has been proven efficient, empirical evidence suggests that the resulting locking rules tend to be cumbersome even for the experienced kernel programmer, leading to bugs that are hard to diagnose. Moreover, scaling to more processors requires extensive use of locks, which may impose unnecessary locking overhead for small scale multiprocessor systems. This talk will describe the typical approach and then discuss the alternative approach taken in the DragonFlyBSD network stack. We will give an overview of the various protocol threads employed for network I/O processing and the common-case code paths for packet reception and transmission. Additionally, we'll need to make a passing reference to DragonFlyBSD's message passing model. This should establish a baseline, allowing us to focus on the recent work by the author to eliminate use of the Big Giant Lock in the performance-critical paths for the TCP and UDP protocols. The decision to constrain this work on the two by far most widely-used transport protocols was made in order to (a) limit the amount of work necessary and (b) explore the effectiveness of the approach on the cases that matter at this point in time.