Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An example proposal #6

Closed
therealgymmy opened this issue Jul 8, 2020 · 1 comment
Closed

An example proposal #6

therealgymmy opened this issue Jul 8, 2020 · 1 comment

Comments

@therealgymmy
Copy link
Contributor

therealgymmy commented Jul 8, 2020

New Feature Foo

Goal

Increase flash space efficiency

Context

This is related to project Bar. It addresses a key gap in its design.

Design

We will add an additional component between X and Y. We will introduce a new API called Hoop.

Success Metrics

  1. No regression on cpu
  2. No regression on read and write latency to flash device
  3. Increase space density by 20%
  4. Added a new metrics here
@therealgymmy
Copy link
Contributor Author

We will introduce a new API called Hoop.

I don't like the name. How about Loop?

@therealgymmy therealgymmy added this to Next Steps in Example Research Project Jul 8, 2020
facebook-github-bot pushed a commit that referenced this issue Aug 16, 2021
Summary:
We recently found cogwheel_cachelib_sanitizer_free_list_stress test failed periodically (T98156036).

Error log:
```
AddressSanitizer: SEGV cachelib/cachebench/runner/Runner.h:54 in facebook::cachelib::cachebench::Runner::abort()
Thread T68 created by T0 here:
    #0 0xeb23232 in pthread_create (/packages/cachelib.cachebench.opt-ubsan-asan/cachebench+0xeb23232)
    #1 0x7fd090412adc in __gthread_create /home/engshare/third-party2/libgcc/9.x/src/gcc-9.x/x86_64-facebook-linux/libstdc++-v3/include/x86_64-facebook-linux/bits/gthr-default.h:663:35
    #2 0x7fd090412adc in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) /home/engshare/third-party2/libgcc/9.x/src/gcc-9.x/x86_64-facebook-linux/libstdc++-v3/src/c++11/../../../.././libstdc++-v3/src/c++11/thread.cc:135:37
    #3 0x4464468 in std::thread::thread<setupTimeoutHandler()::$_1, void>(setupTimeoutHandler()::$_1&&) third-party-buck/platform009/build/libgcc/include/c++/9.x/thread:130
    #4 0x4464468 in setupTimeoutHandler() cachelib/cachebench/main.cpp:88
    #5 0x4464f8f in main cachelib/cachebench/main.cpp:149
    #6 0x7fd0900f2d94 in __libc_start_main /home/engshare/third-party2/glibc/2.30/src/glibc-2.30/csu/../csu/libc-start.c:308:16
    #7 0x4464029 in _start /home/engshare/third-party2/glibc/2.30/src/glibc-2.30/csu/../sysdeps/x86_64/start.S:120

```
The reason should be when one thread is calling `Runner::abort()` after timeout https://fburl.com/code/tpuk95xy, the other thread is executing in the middle of `Runner::run()` after line 54 but before line 55 https://fburl.com/code/7fskwd12. Line 54 set the `stressor_` to be `nullptr` and causes the failure.

To fix that, we should only abort when stressor_ is not nullptr.

Reviewed By: haowu14

Differential Revision: D30318655

fbshipit-source-id: 1974e69c5030c73d52f0517fa721bcd6599cc884
facebook-github-bot pushed a commit that referenced this issue Sep 2, 2021
Summary: Item #6 in https://fb.quip.com/0E0DAhIIU4hu

Reviewed By: sathyaphoenix

Differential Revision: D30712405

fbshipit-source-id: f6a391c013384c7dace060d7c97747d17d01b66e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

1 participant