Skip to content
  • Iustin Pop's avatar
    fb243105
    Improve the `CanTieredAlloc' test · fb243105
    Iustin Pop authored
    
    
    Currently, this test is very slow. Upon investigation, this is due to
    how `tieredAlloc' works:
    
    - tries to allocate one instance
    - if failed, shrink the instance by the "most failed" resource
    - restart
    
    In this algorithm, if the "most failed" resource is e.g. memory, and
    the maximum available memory is much smaller than the current
    template, it means we will have to shrink and try to allocate many
    many times until we finally get with the to-be-allocated instance
    memory size to a reasonable value. In the real world, this is not the
    case, but when testing with arbitrary memory/node values, it can be
    that we execute the shrink hundreds of thousands of times per test.
    
    So we "improve" the test by directly generating an instance just
    slightly bigger than the node, so that we don't have to shrink too
    many times. This requires a new export from test/…/Instance.hs.
    
    Additionally, we allow up to 5 instances to be tiered-allocated, and
    we cleanup the test checks, making the conditions much, much more
    readable (IMHO).
    
    Signed-off-by: default avatarIustin Pop <iustin@google.com>
    Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    fb243105
    Improve the `CanTieredAlloc' test
    Iustin Pop authored
    
    
    Currently, this test is very slow. Upon investigation, this is due to
    how `tieredAlloc' works:
    
    - tries to allocate one instance
    - if failed, shrink the instance by the "most failed" resource
    - restart
    
    In this algorithm, if the "most failed" resource is e.g. memory, and
    the maximum available memory is much smaller than the current
    template, it means we will have to shrink and try to allocate many
    many times until we finally get with the to-be-allocated instance
    memory size to a reasonable value. In the real world, this is not the
    case, but when testing with arbitrary memory/node values, it can be
    that we execute the shrink hundreds of thousands of times per test.
    
    So we "improve" the test by directly generating an instance just
    slightly bigger than the node, so that we don't have to shrink too
    many times. This requires a new export from test/…/Instance.hs.
    
    Additionally, we allow up to 5 instances to be tiered-allocated, and
    we cleanup the test checks, making the conditions much, much more
    readable (IMHO).
    
    Signed-off-by: default avatarIustin Pop <iustin@google.com>
    Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
Loading