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

[scx-layered] add matcher for when tid is pid #1200

Closed
likewhatevs opened this issue Jan 15, 2025 · 4 comments
Closed

[scx-layered] add matcher for when tid is pid #1200

likewhatevs opened this issue Jan 15, 2025 · 4 comments
Assignees

Comments

@likewhatevs
Copy link
Contributor

add a matcher for when tid is equal to pid, to enable filtering tasks by this

@likewhatevs likewhatevs self-assigned this Jan 15, 2025
@likewhatevs
Copy link
Contributor Author

@valentinandrei @htejun @hodgesds does this sound reasonable?

@hodgesds
Copy link
Contributor

Is that different than the PPIDEquals/TGIDEquals match? I think we have most things covered in terms of matches.

@likewhatevs
Copy link
Contributor Author

likewhatevs commented Jan 16, 2025

Is that different than the [PPIDEquals/TGIDEquals match]

This is for filtering threads to those where TGID=PID.

My thinking is we can have a config like the following:

Layer Matches:
CommPrefix: "a thread name for a thread where we only care about the main/first thread"
AND
TGIDEqualsPID: true

Unless I'm missing something, using what we have now, we would need to specify TGID/PID manually.

Edit:

case MATCH_PPID_EQUALS:
return p->real_parent->pid == match->ppid;

is close but I think that isn't exactly what we want.

@likewhatevs
Copy link
Contributor Author

#1204 is an attempt at this.

I think this is needed in addition to MATCH_PPID_EQUALS due to a nuance in the semantics of PID/PPID/TGID across user space and kernel space (I can't find the stack overflow w/ the only diagram I've ever found to make sense of how this works atm.), but I am not 100% sure about that atm (i.e. it could be that MATCH_PPID_EQUALS is sufficient).

In any event, this would do what we expect (get the current group leader thread) regardless of any such nuance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants