Details
Diff Detail
- Repository
- rCTE Clang Tools Extra
- Build Status
Buildable 24320 Build 24319: arc lint + arc unit
Event Timeline
It's fine to spend one thread spinning on background tasks, but if we're going to do a threadpool, we should be more careful to not hurt the performance of foreground tasks. To do that, we should at least:
- share the semaphore for the number of actively running tasks between TUScheduler and BackgroundIndex.
- prioritize foreground tasks over background tasks.
Ideally, probably outside the scope of this change, we should make the background tasks cancellable (or find another way to keep them from interfering with the foreground tasks) in addition to that and make sure the scheduling is aware of distinction between foreground and background tasks. (@sammcall suggested simply using thread priorities for that).
Another high-level comment is that we should probably use llvm::ThreadPool here, this would have give code reuse and would make BackgroundIndex more focused on the actual indexing part.
clangd/index/Background.h | ||
---|---|---|
80 | Why not std::vector? Memory allocs won't ever be a bottleneck here. |
I don't think I agree with this, at least not without evidence. Can we try thread priorities first?
clangd/index/Background.cpp | ||
---|---|---|
92 | I always forget the details of how these work :-\ In general I'm not sure whether the notify_one optimization is worth the correctness risk as the code evolves. | |
clangd/index/Background.h | ||
80 | ilya was saying nice things about llvm::ThreadPool recently - worth a look? |
Moving forward with priorities then.
clangd/index/Background.cpp | ||
---|---|---|
92 | Ah, you are right, a thread waiting for done might catch that one as well, but I think it only applies to that one. Is there a possibility of blockUntilIdleForTest and enqueue being called from different threads? There is still the argument of code evolution, but I don't think we should ever end up in a state in which an enqueue and a wait that will not consume that enqueue should occur concurrently. | |
clangd/index/Background.h | ||
80 | going for llvm::ThreadPool |
Update from the offline meeting: decided to start with llvm::ThreadPool for background tasks and lower thread priorities for background tasks.
clangd/index/Background.cpp | ||
---|---|---|
92 |
We definitely will, +1 to Sam's comment, please call notify_all here. It's too easy to deadlock with notify_one. |
clangd/Threading.cpp | ||
---|---|---|
105 | don't you also need to actually include it? | |
clangd/Threading.h | ||
120 | nit: enum class since this is at clangd scope | |
121 | nit: llvm tends to spell enum values like Low, Normal | |
124 | This deserves a comment - in particular that it may be a no-op. | |
clangd/index/Background.cpp | ||
35 | nit: clang-format | |
37 | we discussed having different priority tasks, which would require priorities to be set up differently (to avoid workers never waking up to consume high priority tasks). OK to leave this for now, but deserves a comment. | |
clangd/index/Background.h | ||
19 | depending on TUScheduler doesn't make sense here. Move the function to Threading.h instead? | |
80 | Any problems with llvm::ThreadPool? |
clangd/Threading.cpp | ||
---|---|---|
104 | Maybe put this helper into llvm/Support/Threading.h? | |
clangd/Threading.h | ||
120 | Maybe use enum class? | |
clangd/index/Background.h | ||
19 | Maybe move the getDefaultAsyncThreadsCount into Threading.h? |
Nice! Sorry about the back and forth with threadpool...
clangd/index/Background.cpp | ||
---|---|---|
35 | (need to clang-format again) |
- Add comment.
clangd/Threading.cpp | ||
---|---|---|
104 | We talked with Sam about that one and rather decided to keep it here for a while and put into LLVM later on when we are sure about it is the right use case for everyone in LLVM with the right API. |
Hi,
I've got a post-review comment about the use of SCHED_IDLE vs the needed gcc version.
clang-tools-extra/trunk/clangd/Threading.cpp | ||
---|---|---|
110 ↗ | (On Diff #171677) | I noticed that when I compile this with gcc 5.4.0, I get a compilation error about SCHED_IDLE not being defined. /* Scheduling algorithms. */ #define SCHED_OTHER 0 #define SCHED_FIFO 1 #define SCHED_RR 2 #ifdef __USE_GNU # define SCHED_BATCH 3 #endif I suppose SCHED_IDLE was added in some later version... On |
nit: enum class since this is at clangd scope