1. 24 3月, 2020 1 次提交
  2. 05 3月, 2020 1 次提交
  3. 04 3月, 2020 1 次提交
  4. 25 2月, 2020 1 次提交
  5. 20 2月, 2020 1 次提交
  6. 04 2月, 2020 1 次提交
  7. 30 1月, 2020 2 次提交
  8. 29 1月, 2020 1 次提交
  9. 24 1月, 2020 1 次提交
  10. 17 12月, 2019 2 次提交
  11. 10 12月, 2019 1 次提交
  12. 09 12月, 2019 12 次提交
  13. 03 12月, 2019 1 次提交
    • D
      qemu: make 'xz' image compression viable by using -3 · 8aaed287
      Daniel P. Berrangé 提交于
      For managed save we can choose between various compression
      methods. I randomly tested the 'xz' program on a 8 GB guest
      and was surprised to have to wait > 50 minutes for it to
      finish compressing, with 'xz' burning 100% cpu for the
      entire time. Despite the impressive compression, this is
      completely useless in the real world as it is far too long
      to wait to save the VM.
      
      The 'xz' binary defaults to '-6' optimization level which
      aims for high compression, with moderate memory usage,
      at the expense of speed.
      
      This change switches it to use the '-3' optimization level
      which is documented as being the one that optimizes speed
      at expense of compression. Even with this, it will still
      outperform all the other options in terms of compression
      level. It is a little less than x4 faster than '-6' which
      means it starts to be a viable choice to use 'xz' for
      people who really want best compression.
      
      The test results on a 1 GB, fairly freshly booted VM are
      as follows
      
        format | save  | restore  size
        =======+=======+=============
        raw    |   05s |    1s  | 428 MB
        lzop   |   05s |    3s  | 160 MB
        gzip   |   29s |    5s  | 118 MB
        bz2    |   54s |   22s  | 114 MB
        xz     | 4m37s |   13s  |  86 MB
        xz -3  | 1m20s |   12s  |  95 MB
      
      Based on this we can say
      
       * For moderate compression with no noticable loss in speed
      
             => use lzop
      
       * For high compression with moderate loss in speed
      
             => use gzip
      
       * For best compression with significant loss in speed
      
             => use xz
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      8aaed287
  14. 22 11月, 2019 1 次提交
    • D
      util: consolidate on one free callback for hash data · bc7e7291
      Daniel P. Berrangé 提交于
      This previous commit introduced a simpler free callback for
      hash data with only 1 arg, the value to free:
      
        commit 49288fac
        Author: Peter Krempa <pkrempa@redhat.com>
        Date:   Wed Oct 9 15:26:37 2019 +0200
      
          util: hash: Add possibility to use simpler data free function in virHash
      
      It missed two functions in the hash table code which need
      to call the alternate data free function, virHashRemoveEntry
      and virHashRemoveSet.
      
      After the previous patch though, there is no code that
      makes functional use of the 2nd key arg in the data
      free function. There is merely one log message that can
      be dropped.
      
      We can thus purge the current virHashDataFree callback
      entirely, and rename virHashDataFreeSimple to replace
      it.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      bc7e7291
  15. 19 11月, 2019 1 次提交
  16. 12 11月, 2019 1 次提交
  17. 21 10月, 2019 3 次提交
  18. 17 10月, 2019 1 次提交
  19. 16 10月, 2019 4 次提交
  20. 15 10月, 2019 3 次提交