1. 20 3月, 2014 18 次提交
  2. 19 3月, 2014 16 次提交
  3. 18 3月, 2014 6 次提交
    • D
      Remove global log buffer feature entirely · c0c8c1d7
      Daniel P. Berrange 提交于
      A earlier commit changed the global log buffer so that it only
      records messages that are explicitly requested via the log
      filters setting. This removes the performance burden, and
      improves the signal/noise ratio for messages in the global
      buffer. At the same time though, it is somewhat pointless, since
      all the recorded log messages are already going to be sent to an
      explicit log output like syslog, stderr or the journal. The
      global log buffer is thus just duplicating this data on stderr
      upon crash.
      
      The log_buffer_size config parameter is left in the augeas
      lens to prevent breakage for users on upgrade. It is however
      completely ignored hereafter.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      c0c8c1d7
    • D
      Switch to filtering based on log source name instead of filename · 975b2392
      Daniel P. Berrange 提交于
      Currently the log filter strings are used in a string comparison
      against the source filename each time log message is emitted.
      If no log filters at all are set, there's obviously no string
      comparison to be done. If any single log filter is set though,
      this imposes a compute burden on every logging call even if logs
      from the file in question are disabled. This string comparison
      must also be done while the logging mutex is held, which has
      implications for concurrency when multiple threads are emitting
      log messages.
      
      This changes the log filtering to be done based on the virLogSource
      object name. The virLogSource struct is extended to contain
      'serial' and 'priority' fields. Any time the global log filter
      rules are changed a global serial number is incremented. When a
      log message is emitted, the serial in the virLogSource instance
      is compared with the global serial number. If out of date, then
      the 'priority' field in the virLogSource instance is updated based
      on the new filter rules. The 'priority' field is checked to see
      whether the log message should be sent to the log outputs.
      
      The comparisons of the 'serial' and 'priority' fields are done
      with no locks held. So in the common case each logging call has
      an overhead of 2 integer comparisons, with no locks held. Only
      if the decision is made to forward the message to the log output,
      or if the 'serial' value is out of date do locks need to be
      acquired.
      
      Technically the comparisons of the 'serial' and 'priority' fields
      should be done with locks held, or using atomic operations. Both
      of these options have a notable performance impact, however, and
      since all writes a protected by a global mutex, it is believed
      that worst case behaviour where the fields are read concurrently
      with being written would merely result in an mistaken emission
      or dropping of the log message in question. This is an acceptable
      tradeoff for the performance benefit of avoiding locking.
      
      As a quick benchmark, a demo program that registers 500 file
      descriptors with the event loop (eg equiv of 500 QEMU monitor
      commands), creates pending read I/O on every FD, and then runs
      virEventRunDefaultImpl() took 4.6 seconds to do 51200 iterations.
      After this optimization it only takes 3.3 seconds, with the log
      APIs no longer being a relevant factor in the running time.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      975b2392
    • D
      Add virLogSource variables to all source files · 2835c1e7
      Daniel P. Berrange 提交于
      Any source file which calls the logging APIs now needs
      to have a VIR_LOG_INIT("source.name") declaration at
      the start of the file. This provides a static variable
      of the virLogSource type.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      2835c1e7
    • D
      Turn virLogSource into a struct instead of an enum · 098dd79e
      Daniel P. Berrange 提交于
      As part of the goal to get away from doing string matching on
      filenames when deciding whether to emit a log message, turn
      the virLogSource enum into a struct which contains a log
      "name". There will eventually be one virLogSource instance
      statically declared per source file. To minimise churn in this
      commit though, a single global instance is used.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      098dd79e
    • D
      Move dtrace probe macros into separate header file · b29275d9
      Daniel P. Berrange 提交于
      The dtrace probe macros rely on the logging API. We can't make
      the internal.h header include the virlog.h header though since
      that'd be a circular include. Instead simply split the dtrace
      probes into their own header file, since there's no compelling
      reason for them to be in the main internal.h header.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      b29275d9
    • D
      Refactor code that skips logging of error messages · 3887c5d8
      Daniel P. Berrange 提交于
      The error reporting code will invoke a callback when any error
      is raised and the default callback will print to stderr. The
      virRaiseErrorFull method also sends all error messages on to the
      logging code, which also prints to stderr by default. To avoid
      duplicated data on stderr, the logging code has some logic to
      skip emission when no log outputs are configured, which checks
      whether the virLogSource == VIR_LOG_FROM_ERROR.
      
      Meanwhile the libvirtd daemon can register another callback which
      is used to reduce log message priority from error to a lower level.
      When this is used we do want messages to end up on stderr, so the
      error code will conditionally use either VIR_LOG_FROM_FILE or
      VIR_LOG_FROM_ERROR depending on whether such a callback is provided.
      
      This will all complicate later refactoring. By pushing the checks
      for whether a log output is present up a level into the error code,
      the special cases can be isolated in one place.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      3887c5d8